Raspberry Pi HQ Camera Compatibility

If you have some very fine soldering iron tips, you could solder on a small SPST switch and use a replacement resistor (or the original R8 resistor, if you can salvage it through desoldering.)
I’ve done similar mods before. A good soldering iron, steady hands, firm work holding, and a good magnifier absolutely help!

You’d basically hook it up as:
R8 pad A → thin wire → switch → resistor → thin wire → R8 pad B

Hi @DavidSoto-RidgeRun, first of all, thanks for working on the driver - it will be great to use HQ camera with Nano.

I’d like to ask for a little clarification regarding the resistor removal mod. Looking at the schematic, removing R8 will make IMX477 chip stay in “enabled” state all the time, rather than be controlled by Jetson’s camera enable pin. My question is: does this mean that the control of XCLR pin is unnecessary, and could as well even be removed from the HQ camera? If otherwise, how is your driver going to go around being unable to control this pin? Perhaps just controlling the voltage regulators is enough?

Additional thought: I wonder if it could be possible to keep control of XCLR pin with Jetson by replacing R8 with 8.8k resistor. For what I understand, the APX803 will keep XCLR low if input voltage is below 2.93 V, and in high-impedance state otherwise. If 8.8k resistor is used as R8, 1.8 V on enable pin will result in (via 4:5 voltage divider with R7 from 3.3 V) 3 V being fed into APX803 - should keep it enabled. On the other hand, 0 V on enable pin will result in 2.64 V into APX803 - should keep it disabled and put IMX477 into reset. Please let me know your thoughts.

Re: soldering. I trust myself to get something like you describe right maybe 1/4 of the time. About the limit of my skills is adding a pi zero header. Anything smaller than that and i’ll probably make a mess out of it. If somebody is skilled enough, however, I’m sure there’s a market for these modified cameras.

thanks to RidgeRun for their initiative to provide the driver. the required hardware modification just kills the whole use case here of utilizing Pi HQ camera in Nano.

  • Very few will consider soldering their camera
  • It will only be used (in case of successful soldering) for nano i.e. he is losing it for Pi

The way forward I see it is that Jetson ecosystem venders to step up and manufacture these cameras in the same way they did for the original Pi camera. There were many options that are designed specifically for Nvidia boards. This is much better in many aspects.

I have purchase Leopard Imaging LI-IMX219-MIPI-FF-NANO which match somehow the same price tag for Raspberry camera and at the same time designed specifically for Nvidia with better lenses. Such initiative is what we are waiting from these venders.

I can see there are many products based on IMX477 but their price tag is above $200 which I believe includes the driver cost. This is done now free of cost. So I guess we should see the prices goes down.

In addition, it might be better to utilise the power of Nvidia SPI here to design the camera in a better way to adopt the full features of this sensor e.g. HDR, 4-lanes for high frames rates instead of 2-lanes

I don’t think any soldering is required to get it working. You just need to snap the resistor off, but I’m hoping a software workaround will be found so that isn’t required. I am personally grateful RidgeRun is going to provide a free driver. Something something gift horse + mouth.

Hi All, we are excited about getting the camera working. Let me provide my comments for each of your concerns:

  1. We posted here the change to be done in the camera because in a previous post I told @riegelbasti that I was going to share the fix to see it in the bus. Now that we can see it we are not longer blocked and we can continue with the driver development.

  2. @mdegans. We have not tested the camera again in the Raspberry PI after removing the resistor, I think it is better to wait until we post the full driver and instructions and then we will get back to see if it works in the Pi again.

  3. @snarky, thanks for the SPST switch trick.

  4. @micmys. You are correct, if we remove the R8 resistor the camera will be always out of reset. This is an easy fix. For driver development this should be enough. We will look for options to see if the camera can be set in standby mode through register settings so it does not consume power if the camera is not being used. At this point, just to validate the concept, we are more interested on getting the camera out of reset, configure it for different resolutions and be sure that we can capture the frames. RidgeRun is a software company, we don’t do hardware, if you can give t a try replacing R8 with a 8.8K resistor and report back if it works it would be great!

  5. @EbrahimAli, It would be interesting to see if after removing R8 if it still works as mentioned by @ mdegans. Once we are done with the driver we will give it a try as well. The Jetson ecosystem partner is strong and there is a high variety of cameras, we just want to give an option to use the HQ camera as well.

We will keep you posted with the progress!

1 Like

Hi All,

The driver now supports 1920x1080@60 and 4056x3040@15. @CarlosR92 added controls for Gain and Exposure. Next step is to work on the ISP calibration file with Leopard Imaging. No stability issues have been seen after removing the control of the reset line (no endurance testing yet). RidgeRun will let you know when it is ready for you to give it a try.

-David

3 Likes

Thank you David for the update. The 4056x3040@15 mode, does it support HDR. I have seen in the datasheet DOL-HDR for this mode. That will be great. Does Nano support doing this in the hardware level.

Hi there,

I have a Jetson Xavier and RPi HQ camera.
Is your driver public already? I couldn’t find it anywhere.

André

Hi All,

The driver is under review. We expect to make it public by the end of this week. It will be free to download and try in Github, so any improvement that you do and want to share with the community please just send a pull request.

-David

7 Likes

David,

Could you update the instruction to work from command line + SD Card, not via SDK Manager

2 Likes

Hi everyone,

We are glad to announce the early-version of the IMX477 Raspberry Pi HQ Camera Compatibility in our Github repo: GitHub - RidgeRun/NVIDIA-Jetson-IMX477-RPIV3: NVIDIA Jetson IMX477 HQ RPI V3 camera driver

You can find documentation about how to build, install and use the driver.

The first version of the ISP config file created by Leopard Imaging was included, you can follow the instructions to use it in your setup.

Looking forward to hearing your feedback.

6 Likes

@CarlosR92, @DavidSoto-RidgeRun big thanks (to Leopard Imaging too) by the effort, solidarity and understanding to bring us this driver, really I think this will be awesome for the community, I hope but I’m sure you and your company going to be rewarded, as this not just show there is good people behind of RidgeRun but competent and reliable staff. For me, no dude, is the first door to call if need a development service.

Os deseo lo mejor, muchisimas gracias.

4 Likes

Thanks @DavidSoto-RidgeRun for the update.

Three questions:

  1. Is the step to remove the R8 resistor still necessary? It wasn’t mentioned on the Github page.

  2. Are there steps for the Jetson Nano? That was my original question here. As you probably know, the Jetson Nano doesn’t have the option to use a Linux host machine for an SDK manager. The Jetson Nano only has the option to use pre-built images from their download center. As @Fredde mentioned, it would be nice if there was a command line option or an SD card image for the Nano.

  3. Does this driver disable the original driver? For ArduCAM’s Jetvariety series, they had a driver that made the original sensor incompatible. (I can’t link cause their site is down at the moment).

Hi @warpstar22,

  1. Yes, you still need to remove the resistor.

  2. This is an early-version of the driver and it was tested in NX. Next week we will continue testing with Jetson Nano but we expect to get it working without a lot of additional work.

  3. There are device tree changes and now it will use the HQ camera, so yes, it will disable the other sensor.

I’m sorry by me ignorance, the 3rd point, what mean? What disable installing this driver? Other camera with the same sensor or the RPi camera v2 ?

@fpsychosis, what I mean is that all the cameras that are said to “work with Jetson Nano” will no longer work. The drivers are made for specific camera sensors. The problem with the Raspberry Pi HQ Camera is that is uses the SONY IMX477 sensor while the Nano’s driver is for SONY IMX219. All the Nano compatible MIPI CSI cameras are using the SONY IMX219 sensor. In using RidgeRun’s driver for SONY IMX477, all cameras using the SONY IMX219 sensor will not be recognized by the Nano.

2 Likes

Hi All,

Basically a V4L2 driver involves 3 parts:

  1. V4L2 Subdevice driver: This is the .c and .h files that contain the initialization of the sensor, i.e, IMX477, IMX219, etc.
  2. Device Tree changes: This is the file that when the system is booting it tells the kernel what drivers to load (like the new driver), on what MIPI ports the cameras are connected, what i2c channel they will use, etc.
  3. Application to test the capture: v4l-ctl, GStreamer, libargus, etc

The GitHub repository contains code to cover 1) and 2). As you can imagine, in order to enable the IMX477 we added changes in the device tree (point 2) to let Linux know where is the camera, etc. However, if after testing the HQ camera you want to use the IMX219 camera again you just need to flash the original device tree that Jetpack installs and you will get the camera working again.

-David

2 Likes

Thanks by the info, for original Nano is clear but new Jetson Nano and NX has two CSI ports, if I need two cameras, does mean I need to buy two RPi HQ cameras (driver affects both CSI ports)? Or in the device tree I can assign a different driver to every CSI port.

You should be able to use one HQ in one port and one IMX219 in the other port. However, you need your device tree indicating that to the kernel. We haven’t tested it yet but it should be possible without a lot of work.

-David

2 Likes