Skip to content

Frequently Asked Questions

NXS is a compact node that connects any MikroElektronika Click sensor (mikroBUS) or MIPI camera to your robot or autonomous system over a single long-distance cable. It handles the hardware interface, driver layer, and data transport — so your team works with sensor data.

Same board, two modes:

  • GMSL — up to 15 m. A single coax carries power, video, and sensor data together. For camera + sensor setups where both need to run over one cable.
  • CAN-FD — up to 40 m (at reduced data rate). Sensor data only, no video. For distributed sensor networks across a chassis or structure.

Teams in robotics, autonomous vehicles, industrial automation, and research who need sensors or cameras placed away from the main compute unit — without writing firmware, porting drivers, or fighting cable-length limits. You don’t need a firmware engineer on the team: plug in a Click board or MIPI camera, and the data arrives on your host in SI units, timestamped, ready to use.

  • Move an existing MIPI camera to GMSL distance — keep your current camera module, place it up to 15 m from compute over a single coax, with power on the same cable. No camera redesign, no USB extenders.
  • Sensor cable runs past USB’s 5 m wall (robot arms, AGVs, chassis-length runs)
  • Heterogeneous sensor mixes (IMU + distance + environmental + camera) on one integration path
  • Camera + sensor over a single coax (GMSL with Power-over-Coax)
  • Distributed sensor networks across a structure (CAN-FD, multi-node)

Can I use NXS for camera only, or sensors only?

Section titled “Can I use NXS for camera only, or sensors only?”

Yes. The two functions are independent: the video path is hardware serialization, and the sensor co-processor is firmware on the STM32 driving the mikroBUS socket. A unit can be deployed for video only, sensors only, or both.

What do I need on the robot/host side — is anything else required?

Section titled “What do I need on the robot/host side — is anything else required?”

That depends on which connector your robot or host computer has. Three cases:

  • Your robot has a GMSL connector (deserializer): connect NXS directly over the coax. You get both video and sensor data on that single cable — no extra units, no additional hardware.
  • Your robot has only a CAN connector: connect NXS over CAN-FD. Video cannot travel over CAN, but sensor data is delivered in full — SI-unit samples, microsecond timestamps, multi-node addressing. The NXS board carries its CAN-FD transceiver, so the NXS side needs no extra hardware; your host needs its own CAN-FD interface. (The transceiver requirement in the Integration & Operation Manual addresses carrier designers integrating the bare co-processor module — the NXS board is such a carrier and satisfies it.)
  • Your robot has only a UART port: connect UART-to-UART (Cyphal/serial, 460800 baud). Same as CAN — sensor data only, no video. No extra hardware needed.
  • You want video but have no GMSL on the host: you need the NXS Hub — a separate device that sits between your NXS nodes and the host computer. The Hub:
    • Aggregates multiple GMSL streams from NXS nodes and forwards the data to the host over MIPI.
    • Supplies power to the link (Power-over-Coax for the connected nodes).
    • Protects the GMSL line from overvoltage, keeping both your NXS nodes and your host hardware safe from electrical faults on the cable run.

One Hub serves two NXS nodes (dual GMSL inputs); you need one per host, not one per sensor.

Can a Jetson or Raspberry Pi use NXS without the Hub?

Section titled “Can a Jetson or Raspberry Pi use NXS without the Hub?”

Yes, for everything except video. Over CAN-FD (a Jetson’s built-in CAN controller, a USB-CAN adapter on either host, or a CAN HAT on a Raspberry Pi) or UART, a single NXS board delivers the complete sensor feature set: SI-unit streams, driver upload, calibration, commissioning, and firmware update. The I²C register map is not available without the link — it is reached through the GMSL side-channel, so it arrives with the Hub. The camera path is GMSL and terminates in a deserializer, so a host with no GMSL input has no video path — that is what the Hub (or a carrier’s own GMSL deserializer input, per the previous question) provides.

Is NXS a development tool or production-ready?

Section titled “Is NXS a development tool or production-ready?”

NXS is an evaluation and prototyping module. It is not certified for safety-critical applications — including automotive safety systems, direct life support or medical devices, weapons systems, or any application where product failure could directly lead to death, personal injury, or severe physical or environmental damage. If you integrate NXS into a final product for commercial deployment, you are responsible for all certifications and regulatory approvals for that final product.


Eight sensor families ship with validated drivers, including the iam20680 6-axis IMU, the ms5611 barometer/altimeter (Altitude 6 Click), and the fxos8700 6DOF eCompass (6DOF IMU 3 Click). The full validated-driver list is the supported-sensors table in the Device Reference.

What about a Click board that isn’t on the list?

Section titled “What about a Click board that isn’t on the list?”

For any other mikroBUS Click sensor on I²C, SPI, UART, AN, or PWM, the nxs-generate-sensor-driver skill generates the driver — it ships in the SDK and runs in a coding agent. A driver is authored as a small Python class, compiled to a portable NXS image on your host, and uploaded to the device — the sensor’s datasheet becomes the code. The device firmware itself is never rebuilt.

In practice the loop is: hand the sensor’s datasheet to the skill, seat the board, nxs upload the generated driver, and nxs stream decoded SI samples — then read or adjust the driver class directly if a register or scale needs a correction; each iteration is an upload, not a rebuild. The compiler refuses anything it cannot compile faithfully, so a driver that uploads is one whose register traffic matches its source.

No. The driver is not compiled into firmware. The on-device virtual machine probes the sensor (cold-reset, WHO_AM_I check), configures it, and produces fixed-size samples. You upload a driver image; you never touch MCU firmware.

Can I swap a sensor without recompiling anything?

Section titled “Can I swap a sensor without recompiling anything?”

Yes — pull one Click board, seat the next one, upload the matching driver image with the nxs tool. No recompile of device firmware.

Physical SI units. Every driver declares per-field name, type, scale, offset, and unit — and samples are projected onto standard uavcan.si.sample.* subjects: acceleration (m/s²), angular velocity (rad/s), magnetic field (T), temperature (K), pressure (Pa). You decode samples to SI without holding the driver file.

Up to 250 Hz sustained over the serial link. Cyphal/CAN-FD runs 1 Mbit/s arbitration / 4 Mbit/s data with a 64-byte MTU.

Yes. NXS publishes as a Cyphal node over CAN-FD or serial, and the nxs host tool bridges that output to ROS 2 topics on your host platform. Pre-built ROS 2 nodes publish microsecond-timestamped topics.

Two built-in paths, no ROS 2 required:

  • I²C register map over the GMSL tunnel — samples, parameters, driver store, commissioning, and firmware update all work over the single coax path, without a CAN bus, serial cable, or Cyphal.
  • Cyphal (OpenCyphal) over CAN-FD or serial — a standards-compliant node; stock tools like yakut and yukon work alongside ours.

Both work at the same time; use either or both.

A single cross-transport host CLI (and Python SDK, NxsClient) that drives every operation over I²C, Cyphal/serial, or Cyphal/CAN: probe, upload/compile a driver, run/stop, read parameters and outputs, stream decoded samples, manage the driver store, set decimation, commission node-ID and subject-IDs, and push firmware.

The nxs wheel is published with each firmware release in the aliensense/nxs repository; one wheel covers the CLI, the Python SDK, and every transport, and the repository carries the nxs-generate-sensor-driver skill under skills/. Install the wheel with pip or uv and make first contact with nxs probe — Getting Started walks through it.

Yes. Node-ID range is 0–125 (default 125; 126 and 127 are reserved), and subject-IDs are writable, persistent registers you can re-commission per node. Sharing a subject-ID across identical boards is intended.

Over the same host transports, via the nxs tool. An interrupted update is harmless: the device keeps or reverts to the previous image automatically and the transfer is simply retried. A last-resort serial recovery exists for an application that no longer boots.

NXS includes open-source components, provided as-is under their respective licenses — see the Third Party Licenses document on the product page. The NXS application software is licensed under the Software License Agreement on the product page.

What if mikroBUS isn’t enough — can I connect my own hardware?

Section titled “What if mikroBUS isn’t enough — can I connect my own hardware?”

Yes. Alongside the mikroBUS socket, NXS exposes an auxiliary board-to-board connector (X2, 30-pin DF40) that breaks out the MCU’s interfaces directly: UART (USART3), the mikroBUS signal set (SPI, I²C, UART, PWM, AN, INT, RST), and fused 5 V power.

Use it to attach hardware the mikroBUS form factor can’t host — for example:

  • VPU / AI accelerator modules — offload vision inference at the sensor edge and let the results ride the same GMSL/CAN-FD link back to the host.
  • FPGA daughterboards — custom preprocessing, triggering, or protocol handling ahead of the NXS co-processor.
  • Custom sensor front-ends — any design that needs direct MCU UART/SPI/I²C access plus power, without conforming to the Click board outline.

The auxiliary board communicates with the NXS compute board over the same signals the mikroBUS socket uses, so the driver model, host transports (I²C register map, Cyphal), and the nxs tooling apply unchanged. Pinout and mating-connector details are in the NXS Datasheet on the product page.


ParameterSpec
Upstream linkGMSL3/2 (up to 15 m) and/or CAN-FD (up to 40 m)
Sensor interfacemikroBUS Click socket (SPI / I²C / UART / PWM / AN / INT / RST)
Image sensorDF40 60-pin, MIPI CSI-2 (2 or 4 lane)
MCUSTM32G491 (Cortex-M4F @ 160 MHz)
Power input12 V (4.7–16 V tolerant); Power-over-Coax on GMSL
TimestampingMicrosecond per-sample timestamps (local clock); host-time translation via the bridge’s synced stamps
Dimensions30 × 40 × 28 mm, 21 g
Housing6061 aluminum alloy, 4 × M2 mounting
  • Operating temperature: −40 °C to +85 °C (industrial grade)
  • Storage: −40 °C to +125 °C
  • ESD: ±2 kV (human-body model, connectors); ESD-protected high-speed lanes
  • Automotive-grade FAKRA connectors and CAN transceiver

Handle the board by its edges, store it ESD-safe and dry, and protect it from moisture, conductive debris, and mechanical shock during operation.

Can I connect the camera or CSI cabling while powered?

Section titled “Can I connect the camera or CSI cabling while powered?”

No. Every connection to the NXS Hub and the host is made cold, with both power supplies removed entirely — a supply that is plugged into mains but switched off still carries ground-potential differences and stored charge that can destroy the host’s CSI-2 inputs. Power up the host first, then the Hub; power down the Hub first, then the host. The NXS Hub datasheet §5.1 is the normative sequence.

Which FFC cable does the Hub’s CSI output take?

Section titled “Which FFC cable does the Hub’s CSI output take?”

A same-side FFC (Type A — also sold as Type 1 or Type BD), 22 positions, 0.5 mm pitch. Never an opposite-side cable (Type D / Type 2 / Type AD): its contacts mirror the pinout end for end, which short-circuits the port and the host the moment power is applied. The two types look identical at a glance — check which side the contacts face at each end before connecting. The NXS Hub datasheet §6.2 carries the requirement.

From a 12 V source (tolerant 4.7–16 V) — no bench supply required in the field. On the GMSL link, the remote serializer side is powered by Power-over-Coax over the same single coax that carries video and sensor data.

Section titled “Will the link hold 15 m in a noisy (EMI) environment?”

GMSL-class links are designed for automotive EMI environments, which are harsher than most robot installations. If the link does not hold in your environment, standard warranty/return terms apply.

CE / FCC Part 15B (Class A) / RoHS / WEEE — status per the product page.


USB’s passive reach is ~5 m; going farther means adding active or optical extenders. NXS runs a single cable 15 m (GMSL, power over the same coax) or 40 m (CAN-FD, power in the same harness).

With micro-ROS you write the firmware yourself, serial reach is ~1 m, and community-reported failure modes include sessions that drop silently with no error or warning. With NXS the driver layer is pre-written (or AI-generated for new Clicks), reach is 15–40 m, and the node is a standard Cyphal citizen.

How is NXS different from camera bridges (Arducam, e-con Systems, Luxonis OAK)?

Section titled “How is NXS different from camera bridges (Arducam, e-con Systems, Luxonis OAK)?”

Those are camera-only solutions — and with several of them you still write the ROS 2 wrapper yourself, or go through an OEM sales cycle instead of buying a board. NXS covers heterogeneous sensors (IMU, distance, environmental…) and camera, with the driver layer included. If you genuinely need camera-only at 15 m and nothing else, a camera-only SKU may serve that single job directly.

How is NXS different from a CAN adapter (e.g. PEAK PCAN-USB)?

Section titled “How is NXS different from a CAN adapter (e.g. PEAK PCAN-USB)?”

A CAN-USB adapter moves CAN frames to a host and leaves the ROS 2 wrapper to you. NXS is the sensor node: it acquires the sensor, timestamps samples in hardware, publishes standard SI subjects, and bridges to ROS 2 topics — no wrapper to build or maintain.

Can I use MikroElektronika’s own toolchain instead?

Section titled “Can I use MikroElektronika’s own toolchain instead?”

Mikroe’s toolchain targets their own compilers (C, Basic, Pascal). NXS keeps the Click ecosystem you already own and adds the missing layer: long-distance transport plus pre-written drivers into ROS 2 / Cyphal.


Order through the product page, or contact sales@aliensense.com for quotations and volume orders. A quotation is valid for 30 days. An order is accepted when we issue a written order confirmation or deliver the products.

Major credit cards and bank transfer (business customers). Payment details are provided at checkout or on your quotation.

Prices are exclusive of VAT, which is added at the applicable rate (currently 5% in the UAE). Business customers: provide your Tax Registration Number for VAT invoicing.

What are the shipping options and delivery times?

Section titled “What are the shipping options and delivery times?”
  • Standard international: 5–10 business days
  • Express international: 2–5 business days

Costs are calculated at checkout by destination and weight. Delivery dates are estimates; risk passes to you upon delivery to the carrier.

Yes, to most countries worldwide. We cannot ship to countries under sanctions, and some products may have export restrictions — we comply with UAE, US, and EU export control laws. You are responsible for import duties, taxes, and customs fees; we provide accurate customs documentation.

  • Before shipping: yes — contact orders@aliensense.com or +971 50 660 5479; we process within 1 business day.
  • After shipping: the order cannot be cancelled; you can refuse delivery or return after receipt (see returns below).

Do you offer educational or volume discounts?

Section titled “Do you offer educational or volume discounts?”

Yes — contact sales@aliensense.com with your institution or volume requirements.

If we increase the price after order acceptance but before delivery, you may cancel within 7 days of notice for a full refund. If we reduce the price within 14 days of delivery, you may request a refund of the difference within 14 days of the change (not applicable to limited-time promotions).

Standard warranty: 1 year from delivery (some products 2 years — check the product page), covering defects in materials and workmanship under normal use. Remedy: repair, replacement, or refund, at our option.

Not covered: misuse, abuse, accidents, negligence; unauthorized modification or repair (the warranty applies to the Unmodified Product); use in unsuited applications; normal wear and tear; consumables; improper installation or operation outside specifications; acts of nature.

Include: your contact details; pickup and ship-to addresses; product model, serial number, and invoice; a description of the issue; and whether you need an immediate replacement. We arrange pickup of the defective unit at our expense and ship the repaired/replacement unit back at our expense. If you request immediate replacement, we ship the replacement first and collect the defective unit afterward. Claims must be reported within 30 days of discovering the problem.

Can I return a product if I’m not satisfied?

Section titled “Can I return a product if I’m not satisfied?”

Defective or non-conforming products: contact us within 14 days of delivery for a return authorization; products must be in original condition, unused.

Standard (non-defective) returns: 30 days from delivery; unused, original packaging, all accessories; 15% restocking fee; customer pays return shipping; refund within 10 business days of receipt and inspection. Note: products are sold B2B, so the 14-day consumer return right does not apply.

Non-returnable: custom or made-to-order products; software licenses once activated; products damaged by the customer or missing original packaging/accessories.

To start a return: email returns@aliensense.com with your order number and reason; we’ll issue an RMA number and instructions.

  1. Photograph the damaged product and packaging.
  2. Keep all packaging.
  3. Email support@aliensense.com within 48 hours of delivery with your order number, photos, and a description.
  4. We send a replacement or issue a full refund, including shipping costs.
  • Email: support@aliensense.com
  • Docs & downloads: product documentation, datasheets, and the nxs tooling on the product page

Yes — contact sales@aliensense.com for custom development and OEM/design-in inquiries.

The NXS Datasheet (electrical ratings, connector pinouts, mechanical) is available on the product page alongside the compliance documents (CE DoC, RoHS, FCC). The register map is specified in the Interface Description; the supported-driver catalog is in the Device Reference.