-
Notifications
You must be signed in to change notification settings - Fork 106
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Query on Pi Camera v3 CSI clock rates #43
Comments
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.
https://github.com/raspberrypi/linux/blob/rpi-5.15.y/drivers/media/i2c/imx219.c#L48
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. |
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. |
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? |
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. |
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. |
@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:
|
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 😃 |
@darksidelemm did you have a chance to look at the results with reduced framerates? |
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. |
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? |
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. |
OK, thanks for that. Please do, as I expect this is going to affect more than just me... |
I've added a |
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. |
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. |
@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 |
could you point to resources on how to do that please (for a different reason) |
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. |
@naushir If you push the change to Github, then CI will build a kernel that can be picked up through |
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. |
Lab testing today showed that it appears to be related to the bit rate on
the cable which is constant and doesn't change with mode of operation. By
tweaking the bit rate on the cable we where able to move the spectral peak
away from 1.575GHz.
…On Fri, 10 Mar 2023, 21:30 Mark Jessop, ***@***.***> wrote:
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.
—
Reply to this email directly, view it on GitHub
<#43 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AEVVFIVZKVGBLTX5AXRAGYLW3OMPHANCNFSM6AAAAAAVAGBXXA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Sure, which is what I suspected it was. Looking forward to trying out a fix! |
Thanks @6by9, I've published the change to https://github.com/raspberrypi/linux/actions/runs/4403064758 for the build artifacts to be available in To get the changes, run To change the clock settings, run the following command (make sure the camera application is not running!):
where |
Has anybody been able to try out the new clock settings? |
Not yet, will be able to give this a go this weekend. |
Well, I did an apt-get update and upgrade, then ran your rpi-update command. |
@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 |
Test hardwareDid 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. |
@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. |
I'm surprised this wasn't picked up in your EMC certification? |
EMC testing is looking for spurious emissions, and immunity to disturbance. 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. |
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... |
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 |
raspberrypi/linux#5381 has now been merged. In order to use this functionality, you will need to add a parameter to
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. |
I'll resolve this issue now, but feel free to reopen if you are still encountering problems. |
When / how can i get these changes via official software distribution channels? |
You can get the changes by running a Eventually the changes will filter into apt and our official images - probably a week or two for the former. |
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? |
@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 info@raspberrypi.com and quote this github issue and perhaps we can look into a quick short-term workaround. |
Is it possible to also fix the same problem for Camera HQ (imx477 overlay)? |
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. |
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. |
@SChancey very interesting, could you elaborate please? How to select correct lengths? You mentioning not to shorten it to 100mm, why is that? |
Luckily, our cables are available in a range of lengths! 😅 |
@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. |
@SChancey thanks for elaborating, make sense |
@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. |
@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. |
@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. |
I've been testing using a Pi Camera v3 for a high-altitude balloon application, where there is a GPS receive in proximity to the raspberry pi. I've previously used Pi Camera v2's with only minimal GPS interference issues, however now I'm testing a Pi Camera v3, I find that as soon as image capture starts, the GPS loses lock.
My suspicion is that the larger sensor size of the v3 results in higher CSI data lane rates, which may have harmonic issues at GPS L1 frequencies (1575 MHz).
How would I determine what CSI rates are in use? I'm capturing full-resolution stills.
Is there any way to force the CSI rate? Again, I'm only interested in capturing the occasional (every few second) still image, not high FPS video...
I've switched back and forth between the Pi Camera v2 and v3, and am fairly certain the issue is more prevalent on the v3 camera.
The text was updated successfully, but these errors were encountered: