I've added a [NOTE] block in the camera documentation pointing at this issue in case others stumble across it.

from libcamera.

The sensor pixel clock rates used by the various modes are listed as (double these up for DDR/2-lane operation):

We will have a go at measuring interference while tweaking various PLL parameters to see what we can come up with.

from libcamera.

@naushir any plans how to proceed?

I think users would prefer to adjust the values of the PLL, just in case of unwanted noise for specific usecases.

For us (and i guess for any other GPS users) the 298 value looks most promising, so maybe this could be a new default value.

I will prepare a change to the driver that allows users to modify the clock frequency through the official V4L2 controls.

Note that I will keep the default frequency as-is (mult value of 300), since all our EMC certification has been run with that value and any change would invalidate it.

from libcamera.

raspberrypi/linux#5381 has now been merged.

In order to use this functionality, you will need to add a parameter to /boot/config.txt to set the required link frequency to use with the following setup:

1. Edit the /boot/config.txt file (as sudo).
2. Find and comment out the camera_auto_detect=1 line.
3. At the bottom of the file, add dtoverlay=imx708,link-frequency=<freq>.

<freq> can take one of the following values (in Hz): 447000000, 450000000, 453000000. These frequencies correspond to a <mult> value of 298, 300, 302 respectively from the earlier tests. The default (in the absence of the link-frequency param) is 450000000,

Unfortunately the camera does not seem to frame correctly with frequencies lower than 447Mhz. It might work with higher frequencies, but that has not been tested.

from libcamera.

Just as confirmation of what's going on here, here's some measurements taken with a HackRF showing the RFI around the GPS L1 frequency when the v3 camera has started:

Here's the same measurement, but with a v2 camera:

In both cases, I use the following python commands to start up the camera:

from picamera2 import Picamera2
cam = Picamera2()
config = cam.create_still_configuration()
cam.configure(config)
cam.start()

from libcamera.

All V4L2 sensor subdev drivers should advertise the CSI-2 link frequency/frequencies used via V4L2_CID_LINK_FREQ. Those are generally configured via device tree too for the case where the driver allows variation of them.

v4l2-ctl -d /dev/v4l-subdev0 --list-ctrls-menu should give you the list, or
https://github.com/raspberrypi/linux/blob/rpi-5.15.y/drivers/media/i2c/imx708.c#L38

#define IMX708_DEFAULT_LINK_FREQ	450000000

https://github.com/raspberrypi/linux/blob/rpi-5.15.y/drivers/media/i2c/imx219.c#L48

#define IMX219_DEFAULT_LINK_FREQ	456000000

Those are both relying on the driver developer having calculated or been given the correct numbers based on the register settings, but I believe they are correct for both sensors.

In both cases the external oscillator feeding the camera module is 24MHz, but the PLLs may result in different frequencies internally.

from libcamera.

Checking the information I have from Sony, the link frequency is correct as 450MHz for all modes.

The internal pixel clock varies based on mode, being 1488MHz for full res, and 1464MHz for binned. HDR mode is 1944MHz, so it might be worth seeing if switching HDR on reduces your interference issue.

from libcamera.

OK, I can try this out and see if it moves the EMI somewhere else, however HDR mode loses me the resolution that I'm after.

Is there any mechanism for adjusting these frequencies?

from libcamera.

Unfortunately HDR mode does not solve the problem. The interference changes from being essentially continuous to now being impulsive (presumably with the frame rate?), but is still very much present and causes as much of an issue as it did previously.

from libcamera.

Is there any mechanism for adjusting these frequencies?

A chunk of the register settings in the driver configure the PLLs. In theory you can change them, but I'm afraid the documentation we have from Sony is under NDA, and it's not something that we would anticipate doing.

@dp111 Any thoughts? Worth a quick discussion on Monday.

from libcamera.

I should note that putting Type-61 ferrites around each end of the camera cable brings the EMI down to the point that it's not taking out the GPS... but I suspect most users of this camera aren't going to have that kind of thing on-hand like I do.

It would certainly be better if it just didn't emit this in the first place.

I'm not 100% sure it's something within the camera module itself - I still suspect it's related to the data transfer from the camera itself.

from libcamera.

@darksidelemm can you try adjusting your framerate to, say, 15fps (66ms duration) to see if/how that changes your interference? You can do this with something like:

picam2.set_controls({"FrameRate": 15.0})

from libcamera.

This reminds me of https://www.stuffaboutcode.com/2014/01/raspberry-pi-gps-helmet-cam.html where the solution was to wrap the CSI-cable in tinfoil 😃

from libcamera.

@darksidelemm did you have a chance to look at the results with reduced framerates?

from libcamera.

Not yet... the hardware I was testing with has been embedded into a balloon payload box so I haven't had the chance to test it.

On that note, I did fly the PiCamera v3 on a balloon launch. With the ferrites it didn't affect the GPS, unfortunately the lens de-focused during the flight due to the cold (certainly out of specification, but still disappointing).

I'll try and get to this this weekend.

from libcamera.

OK, have tried out a few FPS settings (default, 15fps, 1fps). Clearly the duration of the EMI is dependent on how long the data bus is transmitting imagery, but it's still present. I can't say that going to 1fps is a solution here...

Is there any way the CSI clock rate can be adjusted, to see if that shifts the frequency of the EMI around?

Screenshots of results:

from libcamera.

Is there any way the CSI clock rate can be adjusted, to see if that shifts the frequency of the EMI around?

There is no way at present to do this. We will have to talk with the Sony sensors team to discuss if/how this would be possible.

from libcamera.

OK, thanks for that. Please do, as I expect this is going to affect more than just me...

from libcamera.

Is there any way the CSI clock rate can be adjusted, to see if that shifts the frequency of the EMI around?

There is no way at present to do this. We will have to talk with the Sony sensors team to discuss if/how this would be possible.

This problem also prevent us from using the camera in our SearchAndRescue drone searchwing.org .

I would be very much happy if this could be resolved.

from libcamera.

@julled and @darksidelemm, are you able to rebuild the imx708 kernel driver? We have a clocking setup that might possibly eliminate the GPS band interference, but want to do some more testing and validation before we can publish the change.

I can provide the source change here if you are able to test this with a custom kernel.

from libcamera.

@julled and @darksidelemm, are you able to rebuild the imx708 kernel driver? We have a clocking setup that might possibly eliminate the GPS band interference, but want to do some more testing and validation before we can publish the change.

I can provide the source change here if you are able to test this with a custom kernel.

unforunately i dont have capacity to test this right now

from libcamera.

are you able to rebuild the imx708 kernel driver?

could you point to resources on how to do that please (for a different reason)

from libcamera.

@julled and @darksidelemm, are you able to rebuild the imx708 kernel driver? We have a clocking setup that might possibly eliminate the GPS band interference, but want to do some more testing and validation before we can publish the change.

I can provide the source change here if you are able to test this with a custom kernel.

I'm not setup to build a custom kernel. If some instructions were provided I could probably do it. I've only for the RPi Zero W I've been testing on to work with and I'm guessing compiling. custom kernel on that is going to take a long time.

from libcamera.

@naushir If you push the change to Github, then CI will build a kernel that can be picked up through sudo rpi-update pulls/<pull_num>. Saves people needing to do custom kernel builds themselves.

from libcamera.

Also, since I was seeing the same kind of interference in HDR mode (reduced resolution) and full resolution mode, I suspect that the pixel clock is not the issue here.
That the duty cycle of the interference is changing with frame rate suggests that this is likely related to the data transfer from the camera to the Pi.

from libcamera.

from libcamera.

Sure, which is what I suspected it was. Looking forward to trying out a fix!

from libcamera.

Thanks @6by9, I've published the change to https://github.com/raspberrypi/linux/actions/runs/4403064758 for the build artifacts to be available in rpi-update. Please do not do update a production sdcard image, use a spare one or one that you are happy to scrap if things go wrong.

To get the changes, run sudo rpi-update pulls/5381

To change the clock settings, run the following command (make sure the camera application is not running!):

echo <mult> | sudo tee /sys/module/imx708/parameters/iop_pll_mpy

where <mult> is a clock multiplier value. The default value for <mult> is 300. It would be useful to get feedback on <mult> values 298 and 299. If the interference issues are resolved with these values, we will look to update the driver after some more testing.

from libcamera.

Has anybody been able to try out the new clock settings?

from libcamera.

Not yet, will be able to give this a go this weekend.

from libcamera.

Well, I did an apt-get update and upgrade, then ran your rpi-update command.
Now my RPi Zero W isn't connecting to my home WiFi, so I'm going to have to debug why that's the case before I can continue...

from libcamera.

So while the WiFi on my PiZero W still isn't working (I can see the network in iwlist, it's just not connecting after running rpi-update..), I've been able to at least confirm that the different multiplier settings move the interference around.

Default (300), interference centred around 1575 MHz

Set to 299, interference centred around 1570 MHz

Set to 298, interference centred around 1565 MHz

I haven't tested if this is sufficient to reduce the interference to GNSS in my application, as that's a lot more involved to do at this point. It's going to depend a lot on filtering on each individual GNSS receiver. Given the Beidou frequency is 1561 MHz, I expect some receivers may still be affected even at the 298 setting.
I haven't tested camera operability with any of these settings, I've just looked at the RF interference off the CSI cable. Some understanding over what multiplier ranges the camera is stable over would be handy, as if the interference could be moved much further away in frequency (>100 MHz), that would be ideal.

I also note there is a wide-band noise component that is associated with the camera being activated, which is likely to still have some impact on GNSS receivers (though likely nowhere near as much as the main noise 'hump').

The noise hump around 1579 MHz, which is present across all measurements, appears to be something from the RPI Zero W itself, as it occurs whenever I run commands on the RPi (e.g. here's a screengrab with the Pi Idle, then me running 'dmesg', and Ctrl-C'ing the printout after a few seconds):

from libcamera.

We don't want to deviate too far from the nominal multiplier value of 300 - it will have an effect on the camera modes, and in particular the streaming rate. Note that you can lower the value of <mult> to say, 295 or so just for further testing.

If/when do do get to the point of testing this in your application with the GNSS receiver, please do report back.

from libcamera.

The official way to work this would be to support one of a number of different link frequencies being specified via device tree. The dtoverlay would gain a parameter to specify which one to use, and the driver would adopt that and run accordingly (including updating the V4L2_CID_LINK_FREQUENCY property with the appropriate value).

Normal users would therefore be able to remain at the default frequency based on 300, whilst those who need to use an alternate frequency can also be accommodated.

from libcamera.

This reminds me of https://www.stuffaboutcode.com/2014/01/raspberry-pi-gps-helmet-cam.html where the solution was to wrap the CSI-cable in tinfoil smiley

We did exactly that to prevent interference from the camera cables in our SAR UAV. We are looking for shielded cables at the moment but they are hard to find.

from libcamera.

Just as confirmation of what's going on here, here's some measurements taken with a HackRF showing the RFI around the GPS L1 frequency when the v3 camera has started:

Could you share a few bits more about your test setup? Where do you probe and with what probe?

U-Blox GPS have some means of debugging the spectrum too and we used the GPS in the past to debug some of our interference problems. We used u-center from U-Blox to enable the interference plots etc. Shielding and space between the GPS and sources of interference clearly helped to mitigate the problem.

from libcamera.

@darksidelemm - would you be able to email [email protected] and he will be able to give you some specialised HW support.

from libcamera.

Just as confirmation of what's going on here, here's some measurements taken with a HackRF showing the RFI around the GPS L1 frequency when the v3 camera has started:

Could you share a few bits more about your test setup? Where do you probe and with what probe?

U-Blox GPS have some means of debugging the spectrum too and we used the GPS in the past to debug some of our interference problems. We used u-center from U-Blox to enable the interference plots etc. Shielding and space between the GPS and sources of interference clearly helped to mitigate the problem.

In this case I was using a HackRF, with an antenna that is essentially a bit of wire laid across the CSI cable. Of course this is not useful for any kind of absolute measurement, but at least helps with comparing different states (e.g. Camera v2 vs v3, and these new clock multipliers).

In the case of the balloon payload I flew, Type-61 ferrites on each end of the cable (Laird P/N: 28R0898-200, you can see where I put these here: https://twitter.com/vk5qi/status/1627158194438152194) helped considerably with reducing the RFI, while not appearing to degrade the functionality of the camera.

from libcamera.

I did a few tests with a very cheap ublox neo 6M gps (~7€) and your kernel with different settings in a street in a urban enviroment.

Test hardware

• Pi Cam v3 connected to a CM4 based board.
• I connected the GPS via USB UART adapter to my laptop.
  

Test software

Laptop

I use U-Center on the laptop:

• Show GPS values and statistics
• Ability to do Hot/Warm/Cold-restarts of the GPS
  

Pi

Simple Camera script hires images @ 1Hz

#!/usr/bin/python3
import time
from picamera2 import Picamera2, Preview
picam2 = Picamera2(0)
capture_config = picam2.create_still_configuration()
picam2.start()
while True:
    picam2.switch_mode_and_capture_file(capture_config, "test_full_{}.jpg".format(str(0))
    time.sleep(1)

Test Results

Test 1+2+8: First of all i did baselines (pi off and pi on with no camera running) to have numbers to compare against the other settings.

Test 3: shows a low noise value, but while the test it was obvious that the GPS has a very hard time to get GPS satellite signal (signal levels jumping alot!).

Tests 4+5+6+9: I saw that the new setting helps that at least this cheap GPS receiver can get a fix after a warm start, and its also visible that the noise level is reduced the lower the PLL value gets. The Noise level is also almost comparable to the baselines.

Test 7+10: But sadly even with the new setting it still strugles to get a fix in cold start, even with the 298 setting. But at least the signallevels where not jumping around here as in test 3.

limitations

It could be that a better GPS could handle the cold start with the new setting. Maybe someone with a better GPS can try to reproduce the results and try if coldstart works?

It might also be that the urban enviroment with high buildings make it harder for the GPS to get a fix in general...

from libcamera.

@julled thank you for your thorough analysis!

For my own (limited!) understanding, what is the difference between a cold and warm gps starttype?

from libcamera.

@julled thank you for your thorough analysis!

For my own (limited!) understanding, what is the difference between a cold and warm gps starttype?

you can see the differences in wikipedia: https://en.wikipedia.org/wiki/Time_to_first_fix

from libcamera.

Test hardware

Did another test with a USB gps which advertises itself as "u-blox 7" , but its unclear if there a real ublox hidden within the plastic case:

... nevertheless this one works way better

Results

To me now these results look really promising that the 298 setting (test 5) is working out get GPS fixes even if there is a cold start. Also the noise levels look reasonable.
So i think this setting should work for our SAR-drones with GPS in combo.

from libcamera.

@naushir any plans how to proceed?

I think users would prefer to adjust the values of the PLL, just in case of unwanted noise for specific usecases.

For us (and i guess for any other GPS users) the 298 value looks most promising, so maybe this could be a new default value.

from libcamera.

I'm surprised this wasn't picked up in your EMC certification?

from libcamera.

I'm surprised this wasn't picked up in your EMC certification?

EMC testing is looking for spurious emissions, and immunity to disturbance.
I've checked the test reports and we're comfortably below the levels required for FCC, EU, and Korean compliance. The full reports are available under https://pip.raspberrypi.com/categories/799-test-report if you complete the relevant NDA.

GPS receivers are looking for a very weak signal, so it isn't uncommon to have integration issues - those do not fall under compliance requirements.
If you wish to have further discussions with regard compliance, then feel free to email [email protected] and my colleagues can provide some assistance.

from libcamera.

I'm lurking here for different reason - we see interference on video recording from external source and warping cable in foil fixes it, so it is not only GPS...

from libcamera.

We used some foil too. But did someone of you test shielded cables such as:

https://kksb-cases.com/products/dsi-ffc-flexible-flat-cable-15cm

from libcamera.

I'll resolve this issue now, but feel free to reopen if you are still encountering problems.

from libcamera.

raspberrypi/linux#5381 has now been merged.

In order to use this functionality, you will need to add a parameter to /boot/config.txt to set the required link frequency to use with the following setup:

1. Edit the `/boot/config.txt` file (as sudo).

2. Find and comment out the `camera_auto_detect=1` line.

3. At the bottom of the file, add `dtoverlay=imx708,link-frequency=<freq>`.

<freq> can take one of the following values (in Hz): 447000000, 450000000, 453000000. These frequencies correspond to a <mult> value of 298, 300, 302 respectively from the earlier tests. The default (in the absence of the link-frequency param) is 450000000,

Unfortunately the camera does not seem to frame correctly with frequencies lower than 447Mhz. It might work with higher frequencies, but that has not been tested.

When / how can i get these changes via official software distribution channels?
Do newly generated pi-gen images (we can do this on our own) include these changes already?

from libcamera.

You can get the changes by running a sudo rpi-update command. Note, this will update you to the latest kernel and firmware, so please do keep a backup of your critical work on the sdcard if you need to before running this command.

Eventually the changes will filter into apt and our official images - probably a week or two for the former.

from libcamera.

It's worth noting that the PiCamera HQ appears to have exactly the same EMI issue as the Pi Camera 3, with strong EMI present on 1575 MHz.

Are there similar settings changes available for the HQ camera to shift the clock rates around?

from libcamera.

@darksidelemm - it's possible, but right now I don't have the resources to do it so will be lower on the priority list. However, can you email [email protected] and quote this github issue and perhaps we can look into a quick short-term workaround.

from libcamera.

Is it possible to also fix the same problem for Camera HQ (imx477 overlay)?
I have serious problems while using this camera and GPS.

from libcamera.

I should note that I've been able to make the Pi Camera HQ usable in my application with a stock RPi Zero camera cable, but using the ferrite sleeves i've mentioned previously (Laird P/N: 28R0898-200), one near each end of the cable. You can see the layout of my high-altitude balloon payload in this image: https://twitter.com/vk5qi/status/1650750546922569733/photo/1

I am using a uBlox 8-series GPS with a patch antenna, with the antenna located approximately 15cm from the camera. The GPS maintains lock outside with a clear view of the sky, but does have issues inside where it would normally gain lock.

Without the ferrites the GPS does not gain lock however, so they seem to be critical to making it work with the current cable.

from libcamera.

A belated comment but be aware that the ribbon cable used at high (L1) frequencies is also a transmission line. A transmission line (or practically any cable) will act as an antenna for its full and half EMI wavelengths. The "200 mm" ribbon cable is very close to the L1 wavelength. Ferrite beads will add reactance to the cable but altering the ribbon cable's length (moving it away from the L1 wavelength) should be an effective counter-measure to coupling. Don't shorten the cable to a half wavelength (100 mm in this case). For FCC / EMI /RFI product compliance, I always consider interconnecting cable lengths first and if a given cable length happens to correlate to an interfering wavelength, I will shield and / or add respective ferrite cores at the cable ends.

from libcamera.

@SChancey very interesting, could you elaborate please? How to select correct lengths? You mentioning not to shorten it to 100mm, why is that?

from libcamera.

The "200 mm" ribbon cable is very close to the L1 wavelength.

Luckily, our cables are available in a range of lengths! 😅
https://www.raspberrypi.com/products/camera-and-display-cable/
https://www.raspberrypi.com/products/camera-cable/

from libcamera.

@RolandasRazma Practically speaking, from @lurch's links above, going to 300 mm will lower the effective coupling frequency. You don't want 100 mm due to it being close to L1's half wavelength. Imagine a full sine cycle (full wave) and a 1/2 sine cycle (half wave). A simple antenna of appropriate length is "tuned" if it's length matches the effective full or half wave length. If the imposing EM wave, internal or external, matches the antenna length then coupling is increased. This is true for reception and transmission. Fortunately GNSS receiver modules typically employ input SAW filters (high Q bandpass filters) to reject out of band and unwanted wavelengths since they have extremely high input sensitivity (140 dB+). This means you don't have to de-tune the antenna very much to reduce interference. RF is part art, part "magic" and I'm no expert. A rule of thumb for cable / antenna length for an effective frequency is: Frequency (in MHz) = c (speed of light or propagation in meters / sec) / l (length in meters). At the speed of light, it takes ~ 1 nanosecond to travel 1 foot. Real cables don't support propagation at the speed of light and may have speeds in the ~ 0.8 - 0.9 c range. Optimized cables can have higher speeds. Further coupling reduction can be achieved via shielding and / or ferrite cores as mentioned in this thread. In the end, you have to test it. Hard to argue with reality.

from libcamera.

@SChancey thanks for elaborating, make sense

from libcamera.

@naushir Any ideas when the HQ camera will have adjustable frequency as well? Using the camera jams all nearby phones' GPS as well, which is quite problematic.

from libcamera.

@naushir Any ideas when the HQ camera will have adjustable frequency as well? Using the camera jams all nearby phones' GPS as well, which is quite problematic.

This is the problem with raising secondary issues under one issue in an issue tracker - the primary issue gets resolved and the issue closed. The secondary issue therefore gets lost.

I've raised raspberrypi/linux#6004 to track it.

from libcamera.

@03vmate Please consider the 300 or 500 mm camera cables as an option. Cable lengths are discussed above. The 200 mm Standard - Mini Camera Cable normally provided may couple interference in the L1 band. Raspberry Pi states the camera cables are shielded but they really only have a ground plane on one side. This is helpful for transmission lines. My Samsung S21 doesn't have GNSS interference problems with my Pi 5 using a 200 mm camera cable. Not all phones are designed equally of course. Good luck.

from libcamera.

@SChancey Used an FFC-HDMI adapter, so I can run fully shielded cable. Covered the camera and phi in copper tape as much as I could, but there was still significant interference. Adjusting the clock, even by just a few MHz would be nice to have, especially that a lot of other sensors support this.

from libcamera.

@SChancey Used an FFC-HDMI adapter, so I can run fully shielded cable. Covered the camera and phi in copper tape as much as I could, but there was still significant interference. Adjusting the clock, even by just a few MHz would be nice to have, especially that a lot of other sensors support this.

It might be nice, but it isn't related to this issue which is regarding the v3 camera module.

from libcamera.