SIPL HSB_MAX_SENSORS

[daegyu]

HI~!

I’m currently working on a Custom SIPL implementation on AGX Thor with the Holoscan SDK, and I have a question regarding sensor limits on the Holoscan Bridge board.

---

My Setup

• Platform: AGX Thor

• SDK: Holoscan SDK

• Task: Custom SIPL development

• Hardware: Holoscan Bridge Board (Lattice-based)

• Connected Sensors: 5 sensors attached to a single Holoscan Bridge board

---

Issue / Question

While writing the UDDF (Unit Driver Description File), I noticed that HSB_MAX_SENSORS is defined as 2 inside CoEBridgeContext.

This leads me to the following questions:

1. Is it a hardware/driver limitation that only a maximum of 2 sensors can operate via SIPL simultaneously on a single Holoscan Bridge board (single MGBE channel)?

2. If so, is there any workaround to enable all 5 sensors to run through SIPL at the same time?

3. If no workaround currently exists, is there a plan to support more than 2 sensors per board in a future release?

---

Any guidance or clarification would be greatly appreciated.

Thank you!

[ShaneCCC]

Holoscan itself doesn’t impose a fixed camera limit; it’s bounded by the platform hardware and bandwidth, especially on Jetson Thor/IGX with Camera-over-Ethernet (CoE) + Holoscan Sensor Bridge (HSB).

[daegyu]

Thank you for your response.

I understand your point that Holoscan itself does not impose a fixed camera limit, and that it is bounded by the platform hardware and bandwidth (especially on Jetson Thor / IGX with CoE + HSB).

---

However, during my own investigation, I found several things that seem to contradict this — specifically on the SIPL side, not the Holoscan side.

Here is what I found:

1. HSB_MAX_SENSORS is hard-coded as 2 in CoEBridgeContext

2. Setting hsbSensorIndex to 2 or higher in the SIPL JSON file causes the following error:

ERROR: CameraModuleDevice.cpp, line 61: hsbSensorIndex out of range: 2

3. The official SIPL documentation explicitly states:

“hsbSensorIndex must be either 0 or 1”

---

Additionally, I have already confirmed that 3 or more sensors work correctly on the same Holoscan Bridge board using LinuxReceiverOperator, which confirms there is no hardware-level restriction.

---

My Question

Based on these findings, it appears that the limitation does not come from Holoscan or the hardware — but rather from SIPL itself.

Is it correct that SIPL currently has a hard limitation of a maximum of 2 sensors (hsbSensorIndex restricted to 0 or 1) on the Holoscan Bridge board, even though the hardware supports more?

If this is indeed a SIPL-level software limitation:

1. Is there any plan to extend support beyond 2 sensors in a future SIPL release?

2. Is there any workaround available at this time to run more than 2 sensors via SIPL?

Any clarification would be greatly appreciated. Thank you!

[JerryChang]

hello daegyu,

@daegyu

maximum of 2 sensors

that’s due to HSB hardware limitation,
you may refer to Holoscan Sensor Bridge Device Setup - NVIDIA Docs

@daegyu

SIPL-level software limitation

assume it’s CoE (Camera over Ethernet), the maximum sensors is 16.
as you can see.. /usr/src/jetson_sipl_api/sipl/samples/coe_camera/SIPLCoeCamera.hpp
#define MAX_COE_MODULES_PER_PLATFORM 16

[daegyu]

Hello,

Thank you for your response.

I would like to clarify that, in my case, this does not appear to be a hardware limitation.

As mentioned earlier, I designed and built the Holoscan Bridge board myself, and I have already verified correct operation at the hardware level. Specifically, I configured sensors on channel 0, 1, and 2, and confirmed that they operate normally using LinuxReceiverOperator.

For that reason, I believe the hardware path itself is functioning correctly. Since the sensors are working properly at the physical and transport level, I am now focusing on the SIPL integration stage.

My question is therefore separate from the general CoE maximum sensor count.

Although I understand that CoE may support a larger number of sensors in principle, I have not been able to fully verify the SIPL internal behavior because I was informed that the SIPL library source is not available due to IP restrictions.

Based on my current understanding, the hsbSensorIndex field in the SIPL JSON appears to correspond to the sensor channel number. However, when I set hsbSensorIndex to a value greater than or equal to 2, the SIPL library reports an error and initialization fails.

In addition, the documentation explicitly states that hsbSensorIndex must be either 0 or 1.

From a developer’s point of view, this makes it appear as though sensors mapped to channel 2 or higher are not currently usable through SIPL, even if the hardware itself can receive and operate them correctly.

This is exactly the situation I am facing now:
the sensors are functioning correctly at the hardware level, but during SIPL integration, it appears that using more than 2 sensors is not supported.

So I would like to ask for clarification on the following point:

Even if CoE itself can support more sensors, is the current SIPL implementation for HSB effectively limited to hsbSensorIndex values 0 and 1 only?

If that is not the case, could you please clarify:

1. How hsbSensorIndex should be assigned when using 3 or more sensors on HSB

2. Whether channel 2 and above are currently supported in SIPL

3. Whether there is any reference example or recommended method for using more than 2 HSB sensor channels with SIPL

I would appreciate any clarification you can provide. Thank you.

[whitesscott]

Could this work? I’ve only got one stereo camera attached to hsb so can’t test.

#include "NvSIPLCameraTypes.hpp"
#include <cstdint>

using namespace nvsipl;

CameraSystemConfig BuildFiveCoeConfig() {
    CameraSystemConfig config;

    // HSB Transport Config:  Adjust to match your network setup.


    // If all 5 cameras share one HSB:
    CoETransSettings hsb0;
    hsb0.hsbId         = 0;
    hsb0.name          = "hsb0";
    hsb0.interfaceName = "eth0";        // Your host NIC, e.g. "eth0", "enp3s0"
    hsb0.ipAddress     = 0xC0A80001;    // 192.168.0.1 — HSB's IP (big-endian)
    hsb0.vlanEnable    = false;
    hsb0.syncSensors   = true;          // Sync all sensors on this HSB
    hsb0.simulatorMode = false;
    hsb0.hsbMetadataLines = 0U;

    config.transports.push_back(hsb0);

    // If cameras span multiple HSBs, add more CoETransSettings here:
    // CoETransSettings hsb1; hsb1.hsbId = 1; ...
    // config.transports.push_back(hsb1);

    // -------------------------------------------------------
    // Camera Configs — 5 independent mono cameras
    // Replace MAC addresses with your actual hardware MACs
    // -------------------------------------------------------

    auto makeCoeCamera = [](
        uint32_t hsbId,
        const MacAddress& mac,
        uint32_t ipAddr = 0   // 0 = uses HSB's IP (1722 datapath)
    ) -> CameraConfig {
        CoECamera cam;
        cam.hsbId         = hsbId;
        cam.isStereo      = false;
        cam.hsbSensorIndex = 0;       // sensor[0] used when isStereo=false

        std::copy(std::begin(mac), std::end(mac),
                  std::begin(cam.sensors[0].macAddress));
        cam.sensors[0].ipAddress = ipAddr;

        // sensors[1] unused for mono, but zero it out cleanly
        std::fill(std::begin(cam.sensors[1].macAddress),
                  std::end(cam.sensors[1].macAddress), 0);
        cam.sensors[1].ipAddress = 0;

        CameraConfig cfg;
        cfg.cameratype = cam;

        // MipiSettings are typically N/A for CoE (data comes over Ethernet),
        // but the struct requires it — leave defaults unless your platform needs it
        cfg.mipiSettings = MipiSettings{};  // defaults: 4 lanes, DPHY, etc.

        return cfg;
    };

    // Camera 0 — all on HSB 0, adjust MACs/IPs to your hardware
    CameraConfig cam0 = makeCoeCamera(0, {0xAA, 0xBB, 0xCC, 0x00, 0x00, 0x01});
    cam0.name           = "coe_cam0";
    cam0.platform       = "T5000";
    cam0.platformConfig = "coe_5cam";
    cam0.description    = "CoE Camera 0";
    config.cameras.push_back(cam0);

    CameraConfig cam1 = makeCoeCamera(0, {0xAA, 0xBB, 0xCC, 0x00, 0x00, 0x02});
    cam1.name = "coe_cam1"; cam1.description = "CoE Camera 1";
    config.cameras.push_back(cam1);

    CameraConfig cam2 = makeCoeCamera(0, {0xAA, 0xBB, 0xCC, 0x00, 0x00, 0x03});
    cam2.name = "coe_cam2"; cam2.description = "CoE Camera 2";
    config.cameras.push_back(cam2);

    CameraConfig cam3 = makeCoeCamera(0, {0xAA, 0xBB, 0xCC, 0x00, 0x00, 0x04});
    cam3.name = "coe_cam3"; cam3.description = "CoE Camera 3";
    config.cameras.push_back(cam3);

    CameraConfig cam4 = makeCoeCamera(0, {0xAA, 0xBB, 0xCC, 0x00, 0x00, 0x05});
    cam4.name = "coe_cam4"; cam4.description = "CoE Camera 4";
    config.cameras.push_back(cam4);

    return config;
}

[daegyu]

Thank you for your reply.

However, I am sorry to say that I did not fully understand what source code example you were referring to in your response.

I am currently testing with the NVIDIA Holoscan Sensor Bridge software, and below is a partial excerpt from my actual application code and configuration.

SIPL test code

Copysipl_capture = hololink_module.operators.SIPLCaptureOp(
    self,
    condition,
    name="sipl_capture",
    camera_config="custom_sensor",
    json_config=self.json_config,
    raw_output=True,
)

SIPL JSON configuration

Copy"CoECamera": {
    "isStereo": false,
    "hsbSensorIndex": 2,
    "hsb_id": 0,
    "sensor": {
        "mac_address": "8c:1f:64:6d:70:03",
        "ip_address": "192.168.0.2"
    }
},
"sensor"

Error message

Copy[HSB] ConfigureDriver - IP 192.168.0.2, HSB ID 0
[HSB] ProbeHardware
INFO 0.1134 hololink.cpp:1749 configure_hsb tid=0xb1 -- HSB IP version=0x24072510 datecode=0x1f650000
INFO 1.3174 hololink.cpp:1749 configure_hsb tid=0xb1 -- HSB IP version=0x24072510 datecode=0x1f650000
ERROR: CameraModuleDevice.cpp, line 61: hsbSensorIndex out of range: 2

At the same time, I also tested the sensors using LinuxReceiverOperator, and I was able to confirm normal operation with 3 sensors. Below is part of the code I used for that test.

LinuxReceiverOperator test code

Copyoverride_strategy = hololink_module.BasicEnumerationStrategy(
    hololink_module.Metadata(), total_sensors=3
)
hololink_module.Enumerator.set_uuid_strategy(fpga_uui, override_strategy)

meta_camera_1 = hololink_module.Metadata(channel_metadata)
hololink_module.DataChannel.use_sensor(meta_camera_1, 0)

meta_camera_2 = hololink_module.Metadata(channel_metadata)
hololink_module.DataChannel.use_sensor(meta_camera_2, 1)

meta_camera_3 = hololink_module.Metadata(channel_metadata)
hololink_module.DataChannel.use_sensor(meta_camera_3, 2)

rx_camera_0 = hololink_module.operators.LinuxReceiverOperator(
    self,
    condition_camera_0,
    name="rx_camera_0",
    frame_size=self._cam0_device.get_total_frame_size(),
    frame_context=self._cuda_context,
    hololink_channel=self._hololink_channel_camera_0,
    device=self._cam0_device,
)

rx_camera_1 = hololink_module.operators.LinuxReceiverOperator(
    self,
    condition_camera_1,
    name="rx_camera_1",
    frame_size=self._cam1_device.get_total_frame_size(),
    frame_context=self._cuda_context,
    hololink_channel=self._hololink_channel_camera_1,
    device=self._cam1_device,
)

rx_camera_2 = hololink_module.operators.LinuxReceiverOperator(
    self,
    condition_camera_2,
    name="rx_camera_2",
    frame_size=self._cam2_device.get_total_frame_size(),
    frame_context=self._cuda_context,
    hololink_channel=self._hololink_channel_camera_2,
    device=self._cam2_device,
)
Copy

Based on these tests, what I have confirmed so far is the following:

• The hardware path itself is working correctly

• Sensor channels 0, 1, and 2 can all be enumerated and operated successfully with LinuxReceiverOperator

• In contrast, with SIPL, hsbSensorIndex values 0 and 1 work, but starting from hsbSensorIndex = 2, the SIPL library reports an error and initialization fails

• The official documentation also seems to indicate that only 0 and 1 are valid values for hsbSensorIndex

  

This is why I raised the question.

My understanding is that the hardware and transport path are functioning correctly, but SIPL appears to reject channel 2 and above during initialization.

So I would appreciate clarification on the following points:

1. Am I misunderstanding the meaning of hsbSensorIndex?

2. Does hsbSensorIndex actually correspond to the sensor channel number on HSB?

3. If not, how should channels 2 and above be represented in the SIPL JSON configuration?

4. If yes, does the current SIPL implementation for HSB support only indices 0 and 1?

At the moment, based on both the runtime behavior and the documentation, it looks as if only sensor channels 0 and 1 are supported in SIPL, which is why I am asking for clarification.

Could you please confirm whether this is expected behavior or a current limitation?

Thank you.

[ShaneCCC]

I think it could be one JSON file support only 0 or 1 hsbSensorIndex define.

Thanks

[daegyu]

Thank you for your reply

Just to confirm: does this mean SIPL currently supports only 2 sensors per Holoscan Sensor Bridge board (hsbSensorIndex 0 and 1 only)?

Since SIPL is provided only as a binary library, I have no way to modify it, so I do not see any way to access channel 2 and above.

Is that correct?
If yes, is there any plan to improve this in a future release?

Thank you.

[ShaneCCC]

What’s your HW connection?

4 sensor on one HSB?

[daegyu]

Thank you for reply

Yes, that’s correct — I have 5 sensors connected to one HSB board (mgbe0), so I need 5 channels to be available on that single board.

However, from the SIPL side, it seems that only 2 channels can be used per HSB board (hsbSensorIndex 0 and 1 only).

That is the point I am trying to clarify.

Thank you.

[ShaneCCC]

I think the HSB support 2 cameras per mgbe0(one IP address)

Thanks

[whitesscott]

I saw your post and looked at /usr/src/jetson_sipl_api/sipl/include/NvSIPLCameraTypes.hpp and wondered if it could be used to access 5 cameras, so drafted the code posted above.

[daegyu]

Thank you for the clarification.

May I confirm whether SIPL currently supports only 2 cameras per HSB / per mgbe0 (per HSB IP address)?

In my setup, 5 sensors are connected to a single HSB board, but in SIPL only hsbSensorIndex 0 and 1 appear to be usable.
So it seems that channels 2 and above are currently not accessible through SIPL.

If that understanding is correct, could you also let me know whether there is any workaround or any plan to support more than 2 channels in a future release?

Thank you again.

[ShaneCCC]

Suppose yes. I think 5 sensors using one mgbe would have bandwidth concern.

@daegyu

May I confirm whether SIPL currently supports only 2 cameras per HSB / per mgbe0 (per HSB IP address)?

[daegyu]

Hello,

Bandwidth is not the issue in my setup — I already verified that.

Is there any plan to support more than 2 sensors per mgbe in a future release?

Thank you.

[ShaneCCC]

JP7.2 will fix the limitation.

Thanks

[whitesscott]

You could look to see if any of the commits making up 2.6.0-EA and the 2603 Firmware add anything helpful for you.

https://github.com/nvidia-holoscan/holoscan-sensor-bridge/tree/release-2.6.0-EA

HSB-sdk version 4.1 
holoscan-cuda-13/unknown,stable,now 4.1.0.1-1 arm64 [installed]
  NVIDIA Holoscan