HQ camera link frequency can cause GPS distruption

[6by9]

Describe the bug

From raspberrypi/libcamera#43, the same issue of GPS interference has been noted on the HQ camera as well as the v3 that has already been fixed.
Look at tweaking the PLL settings to move the peak away from GPS on 1575MHz.

Steps to reproduce the behaviour

See raspberrypi/libcamera#43

Device (s)

Raspberry Pi 4 Mod. B

System

All kernels as the link frequency has never varied.

Logs

No response

Additional context

No response

[kinnersley]

Hi, any update on this? I see that it hasn't been taken on yet. Any tips on how to resolve it as I have a whole load of these cameras inside units with GPS and when then camera is on you can kiss goodbye to GPS signal!

[6by9]

I had 30mins spare, so have done the quick patch to add it (based on imx708).
#6468

Give it 40mins for CI to run, and you should be able to get the test kernel using sudo rpi-update pulls/6468. Please ensure anything critical is backed up first.

Same as imx708, you can load dtoverlay=imx477,link-frequency=447000000 or dtoverlay=imx477,link-frequency=453000000 to shift the link frequency by those few MHz. 447MHz needs a little more testing before merging, but 453MHz should have no issues.

[kinnersley]

This is great, I will give it a try with a new kernel.

Question...

I also have a legacy version that I need to support, with kernel 5.4.154. I build from a snapshot so I can apply code changes. Is it sufficient to just edit the line:

#define IMX477_DEFAULT_LINK_FREQ 450000000

Or could that cause problems and I need to apply the other changes to make it configurable etc?

[kinnersley]

Ok that didn't work on the old kernel. Do I need to change some registers as well?

[6by9]

Just changing IMX477_DEFAULT_LINK_FREQ will do nothing other than change the value advertised to userspace. Actually it may stop the driver probing as then the configured link frequency isn't the supposedly supported one.

If you want to do the quick hack, then changing register 0x030f from 0x96 to 0x97 or 0x98 in the table of registers would make the change without telling the rest of the system about it (it's not a critical thing for anything else to know about). Do note that it occurs multiple times.

[kinnersley]

I've tried it out and with a 200mm unshielded camera cable there is still some interference at 453, 456 and I even tried 459. It's better but still causing some signal loss. How high can we take the link frequency, do you know? Could it go up even higher without causing issues/damage?

[kinnersley]

Also is there some way of double checking that the link frequency change has worked? Something I can call to return the current link frequency?

[6by9]

You could go up to 500MHz and still be compliant with the CSI2 spec v1.0 as implemented on Pi0-4.
The IMX477 supports link frequencies up to 1.05GHz (2.1Gbit/s), and #6208 was trying to utilise that for Pi5 (supports up to 750MHz / 1.5Gbit/s) and getting higher frame rates at higher resolutions.

The module has been EMC tested with the values in the driver as they were at 450MHz, so any significant changes technically should result in redoing EMC testing.

v4l2-ctl --list-ctrls-menu -d /dev/v4l-subdev0 should give you a dump that includes the link frequency, such as

Image Processing Controls

                 link_frequency 0x009f0901 (intmenu): min=0 max=1 default=0 value=0 (456000000 0x1b2e0200) flags=read-only
				0: 456000000 (0x1b2e0200)
				1: -204673903784 (0xffffffd0587c1358)

(oops, I appear to have an extra entry in there - one to fix!)

Alternatively you can use i2ctransfer to manually poke the registers whilst streaming.
i2ctransfer -y -f 10 w2@0x1a 0x03 0x0f r1@0x1a should read back the current value, whilst i2ctransfer -y -f 10 w3@0x1a 0x03 0x0f 0x99 would increase it to 459MHz.

[6by9]

#6483 to fix the link frequency menu having the rogue entry in it.

[kinnersley]

I get:

Cannot open device /dev/v4l-subdev0, exiting

and...

# i2ctransfer -y -t 10 w2@0x1a 0x03 0x0f r1@0x1a
Error: Unsupported option "-t"!

and...

# i2ctransfer -y w2@0x1a 0x03 0x0f r1@0x1a
Error: I2C bus name doesn't match any bus present!

[6by9]

Grr, typo. -f (for force), not -t, and in the second case you've removed the 10.

[kinnersley]

I only have a /dev/i2c-11 and I get...

# i2ctransfer -y -f 11 w2@0x1a 0x03 0x0f r1@0x1a
Error: Sending messages failed: Operation timed out

Thanks for helping with this!

Update: sorry ignore the above, the camera wasn't running. However, even though I edited the registers in the kernel source code it is still reading as 0x96

# i2ctransfer -y -f 11 w2@0x1a 0x03 0x0f r1@0x1a
0x96

If I change the register with i2ctransfer will it change the link frequency on-the-fly?

I tried this...

# i2ctransfer -y -f 11 w3@0x1a 0x03 0x0f 0x99

Then I got:

# i2ctransfer -y -f 11 w2@0x1a 0x03 0x0f r1@0x1a
0x99

Then I stopped the camera and started it again and got:

# i2ctransfer -y -f 11 w2@0x1a 0x03 0x0f r1@0x1a
0x96

[6by9]

Yes you can change the registers on the fly.
I don't know why you only have an i2c-11 - something weird on your system if that's a standard Pi4.

[kinnersley]

I can confirm it's working in the latest Bookworm, but I've not been able to get it work with the old kernel.
Would this same kernel work with Bullseye or would I need to build a custom kernel for Bullseye?
I need legacy camera support and the original picamera library (otherwise I have to change a LOT of code) so need to get this hack into an older kernel somehow!

Any advice appreciated

[kinnersley]

Update: On bullseye I was able to pull the new kernel and apply the new link_frequency and it works fine in libcamera - can see 0x97 at 0x030f with i2ctransfer
However, when using legacy camera (raspivid or picamera) the link_frequency is always 0x96 at 0x030f

Does the legacy stack override the registers in the kernel driver??

[6by9]

The legacy camera stack is baked into the firmware and doesn't touch the kernel drivers at all.

And it's deprecated (replaced by libcamera), so there won't be any changes there.

[david-delmoral]

Hi I am facing severe GPS interference from the HQ camera module for a UAV.
I have tried changing the link frecuency with dtoverlay=imx477,link-frequency=453000000 but I cannot appreciate any improvement on GPS signal quality going from 450 MHz to 453 or 456.
The thing is that at first, changing the dtoverlay had no effect but after a sudo apt update and sudo apt upgrade, v4l2-ctl --list-ctrls-menu -d /dev/v4l-subdev0 shows the modified frequencies without having to update with sudo rpi-update pulls/6468.

How can we be 100% sure that the frequencies are being chaged? Has anyone actually been able to fix the interference just by adjusting the frequency in the dtoverlay?
Any help would be much appreciated

[6by9]

The PR was merged back in November, so is in the latest standard builds. You therefore don't need to use rpi-update or anything else to get a testing kernel.

Shifting the link frequency was sufficient on imx708 for those that had reported issues.
#6483 implemented largely the same change for imx477. If it isn't sufficient for your use case, then ensure you've taken basic measures of physical separation of GPS receiver and camera cable, and potentially wrap the camera cable in foil to screen it. The recent Pi camera cables have a ground plane built in to improve impedance matching and reduce emissions.

As per the comment at #6004 (comment), we could increase the link frequency up to 500MHz, but technically that means putting the module through EMC testing again.

[6by9]

#6617 adds extra link frequency options of 459, 462, and 498MHz.

I haven't tested them. If you have issues of GPS interference and wish to pursue it, then please test.
CI builds should be complete in about 40mins, and available for the next 90 days. You can install it using sudo rpi-update pulls/6617, but normal warnings over not using a critical system with rpi-update.

[kinnersley]

Hi, I tried to do sudo rpi-update pulls/6617 but I got the following error:

update-initramfs: Generating /boot/initrd.img-6.6.72-v8+
grep: /boot/config-6.6.72-v8+: No such file or directory

Also can you explain what you mean by "CI builds should be complete in about 40mins, and available for the next 90 days"?

[6by9]

Also can you explain what you mean by "CI builds should be complete in about 40mins, and available for the next 90 days"?

I mean that CI builds complete in about 40 mins, and the artifacts are retained for 90 days.
I've just run sudo rpi-update pulls/6617 on my system running Raspberry Pi OS Bookworm here, and it's grabbed the build fine and installed it.
Now this is my development system so I've hacked it around with new kernels already. I'd suggest trying setting auto_initramfs=0 in /boot/firmware/config.txt and rebooting before trying rpi-update again.

[pelwell]

"CI" stands for Continuous Integration, which is a fancy way of saying we run a build on every change (and suggested change). The "artifacts" are the kernel image, modules and Device Tree files, which are what you can install using sudo rpi-update pulls/..., as long as you do it within 90 days of the build occurring.

[kinnersley]

Thanks for the clarification guys. The kernel build was installed fine but it won't generate the initramfs and so overlayroot will no longer work. If I revert back to 2024-11-19 stable image then the link-frequency parameter doesn't work (and in fact stops the camera from working entirely). Only if I do sudo rpi-update pulls/6617 does the camera work with link-frequency but then overlayroot no longer works when enabled through raspi-config

Any ideas?

[kinnersley]

Just to reiterate - the link frequency changes do not work with the current OS release and pulling kernel from 6617 results in reduced functionality (such as, in my case, overlayroot not working).
Does anyone know when the next standard release will be that will include the link-frequency changes? Or does anyone know how to resolve the issues after the kernel pull (being that /boot/config-6.6.72-v8+ is missing)?

[6by9]

Changes generally aren't merged until they're confirmed to work.

The basic options for link-frequency (453 and 456MHz) were merged in November 2024, so will be in the standard kernel of 6.6.64 or above (current in Raspberry Pi OS Bookworm is 6.6.74)

You've said

Only if I do sudo rpi-update pulls/6617 does the camera work with link-frequency

So which value for link-frequency has actually resolved your interference issue? Do we need the 498MHz option that I threw in as a worst case whacky one to totally avoid GPS frequencies, but possibly interferes with something else?

[kinnersley]

According to the release notes, and my experience of the latest standard release it's v6.6.51...

2024-11-19:
  * Fix bluetooth rfkill whitelisting
  * Fix Imager NM WLAN unblocking
  * Raspberry Pi firmware a2e586ba98ce68f7d11b1c717ad8329b95dcb3b6
  * Linux kernel 6.6.51 - 5aeecea9f4a45248bcf564dec924965e066a7bfd

Even #6617 from Jan 20th only pulls v6.6.72

Regarding the interference, there is a noticeable improvement for me on any frequency other than the default one! Though, I've not personally tried 498MHz but will be interested to do so.

[6by9]

https://archive.raspberrypi.com/debian/pool/main/l/linux/ would beg to differ. You've had a 6.6.62 and 6.6.74 release since 6.6.51.

I assume you've done a normal sudo apt update sudo apt full-upgrade as per the normal approach for updating images (documentation at https://www.raspberrypi.com/documentation/computers/os.html#install-updates)

@david-delmoral had said that 453MHz was insufficient for his use case, hence PR #6617. However he hasn't come back to say whether it helps or not. That won't get merged unless there is a reported improvement in using it.

[kinnersley]

This is just the standard download image I'm referring to, from Nov 19th, that has kernel version 6.6.51. i.e. if your device doesn't have internet connectivity for upgrading.

If I can solve the overlayroot issue with pulling #6617 then I can test the 498MHz link-frequency, Any ideas on how to fix that?

[6by9]

Full images are created a couple of times a year as they get a fair amount of testing done on them.
The repos are updated continuously, and hence you are recommended to upgrade when possible.
Holding out for a new image release is going to be time consuming.

Seeing as you obviously have an internet connection if you're using rpi-update, and you've said that anything other than the default rate solves your problem so just using apt will fix your issue, there is no point in trying to debug your system for #6617.

[kinnersley]

Ok I might just go ahead and test 498MHz without overlayroot and just do manual shutdowns, that way I can report back so that if it is even better than 453/456 then it can be merged into the next release

[kinnersley]

After testing the additional link-frequencies I can confirm that 459MHz and 498MHz are the best followed by 453MHz and 456MHz.
462MHz causes some interference for me but is still better than the default 450Mhz

I guess mileage could vary based on which GPS receiver, camera cable and even the enclosure you are using, so having as many options as possible seems ideal to me!

[6by9]

As long as all link frequencies are still functional from the camera side, then I'm happy to merge #6617.

@naushir any comment?

[kinnersley]

I tried 462MHz again and it works fine, not sure what the problem was the first time...must have been something else.

Camera itself works with no problems, on all frequencies

[naushir]

#6617 is now merged.

[kinnersley]

This is great, thanks guys. Any idea when there will be a new kernel in the update stream? Looks like there hasn't been one since January.

[6by9]

The plan is to shift to 6.12 for the next kernel release, but there are a couple of changes still desired to be made before that.