240p via HDMI on Raspberry Pi to RGBS, no need for RGB hats!

[setiawan]

Trying to do 480i and getting this picture: https://i.imgur.com/zlo1sSS.jpg

Any ideas why? The chain is Rpi4 -> Portta HDMI to VGA -> RGBHV input on JVC TM-H150CG.

hdmi_group=2 and hdmi_mode=6. I get the same thing with hdmi_mode=10 (pixel quadrupling).

Strange thing is when I run `tvservice -s`, it says that it's outputting 1920x1080.

When I try to do 240p or super resolutions via hdmi_cvt though, they work properly.

Anyone run into similar problems trying to get 480i to work?

---

edit:

Okay, to add some information, it only looks that way once you enter emulationstation (I'm running retropie). When the boot picture appears, it produces a stable image. I've prevented emulationstation from autostarting now, by commenting out the lines that start it in the autostart script. However, no command line interface appears after booting. If I SSH in and do `tvservice -s`, it says that the picture is 720x480 interlaced.

It's strange enough that the command line doesn't appear (though it is actually there, since I can type commands like 'reboot' and it'll reboot). I've been able to start VLC via SSH and streamed YT videos, and strangely it looks like the image is lower resolution than 480i. I've run 480i via HDMI->S-Video converter and the picture was much clearer. The picture looks mildly blockier now, as if every second pixel is doubled. When I take a screenshot though, the picture appears correct.

Anyone know what might be going on with any of this?

edit 2: to be clear, when I run `tvservice -s`, it says: state 0xa [HDMI CEA (6) RGB full 4:3 x2], 720x480 @ 60.00Hz, interlaced

Can I assume that 'x2' is pixel doubling, and the cause of the seemingly lower resolution? The Rpi documentation doesn't list 'pixel doubling' next to hdmi_mode 6, so it's a little confusing..

[Fudoh]

can't help, since my CRT setup is still pi3-based, but what's weird here is that to my knowledge ES doesn't have any function to influence the output resolution. While the emulators themselves can be set to any resolution you want, ES is following what the config.txt orders.

The only thing I can think of is the postprocessing scaling that Retropie activates by default. I think this is set using the render resolution and it's made so you can run emus internally at a lower res, but still get 1080p output. I wouldn't know why this would influence ES though since it sits above retroarch and the rendering resolution shouldn't be read unless an actual emu is launched.

[vol.2]

I loaded up Retropie on my Pi4 last month, and I tried mode 6 and did not see that behavior.

I'm thinking maybe it has either something to do with KMS or you have an older firmware revision. The Pi4 is different from the Pi3 in that it has real firmware; there is an EEPROM on the board that get flashed. There were definitely some bugs in the firmware last year, so it would be worth trying to update it if you haven't done so in a long time.

If it's KMS, then you have to check the settings in config.txt relating to V3D and VC4; I'm pretty sure that I was running FKMS when I tested.

That being said, if ES and everything is working fine when it boots, maybe you don't have to worry about it. The only trouble I can see is that Retropie goes back into the console when you assign settings in Retroarch, so you might see the same behavior in those screens. I would try that out.

[Bahn Yuki]

Do any of you have and any recommendations for s video output? I have a retrotink ultimate which works fine for rpi3, unfortunately it just gives me black and white on rpi4.



Sent from my SM-G970U using Tapatalk

[vol.2]

Do any of you have and any recommendations for s video output? I have a retrotink ultimate which works fine for rpi3, unfortunately it just gives me black and white on rpi4.

Did you try toggling the sync switch? I think maybe it has to be in csync mode to work with svideo.

I would try it here, but I don't have an svideo cable long enough, and I installed my Pi4 on a board inside a rack.

[Bahn Yuki]

Do any of you have and any recommendations for s video output? I have a retrotink ultimate which works fine for rpi3, unfortunately it just gives me black and white on rpi4.

Did you try toggling the sync switch? I think maybe it has to be in csync mode to work with svideo.

I would try it here, but I don't have an svideo cable long enough, and I installed my Pi4 on a board inside a rack.

Yes i have tried it. I have not updated pi4 firmware in a long time. Can you send me a pm with the firmware links and your ini?

Sent from my SM-G970U using Tapatalk

[vol.2]

Yes i have tried it. I have not updated pi4 firmware in a long time. Can you send me a pm with the firmware links and your ini?

Ok. I sent you the links to firmware info.

I don't know what my "ini" is. I don't have a file with that extension in my boot folder, or in my retroarch folder.

I am beginning to think that maybe your issue is also related to Lakka, if you are using that. It's pretty out of date as things have changed a lot for the Pi4 over the past year.


Also, let me be clear; I have not tried svideo with my setup. I can try maybe over the weekend, but it's not convenient for me to dismantle my equipment ATM.

[setiawan]

what's weird here is that to my knowledge ES doesn't have any function to influence the output resolution.

Yeah strange. It doesn't seem to affect 240p (hdmi_mode=8), but for some reason 480i causes it to change, and i have no idea why.

I'm thinking maybe it has either something to do with KMS or you have an older firmware revision. The Pi4 is different from the Pi3 in that it has real firmware; there is an EEPROM on the board that get flashed. There were definitely some bugs in the firmware last year, so it would be worth trying to update it if you haven't done so in a long time.

If it's KMS, then you have to check the settings in config.txt relating to V3D and VC4; I'm pretty sure that I was running FKMS when I tested.

I updated the firmware a few weeks ago to 5.10.9-v7l+, and I'm also using fkms (dtoverlay=vc4-fkms-v3d). For reference, my whole config.txt (without the comments):

Code: Select all

disable_overscan=1
dtoverlay=vc4-fkms-v3d
max_framebuffers=1
hdmi_drive=2
hdmi_group=1
hdmi_mode=6
hdmi_pixel_encoding=2
hdmi_drive=2
hdmi_force_mode=1
hdmi_force_hotplug=1
gpu_mem_256=128
gpu_mem_512=256
gpu_mem_1024=512
dtparam=audio=on

That being said, if ES and everything is working fine when it boots, maybe you don't have to worry about it. The only trouble I can see is that Retropie goes back into the console when you assign settings in Retroarch, so you might see the same behavior in those screens. I would try that out.

Well it works fine in 240p as mentioned, but trying to set 480i is all garbled (i.e. the photo in my previous post). Maybe I'll just live with booting at 240p for ES's sake so it's at least usable. I've started a thread on the raspberry pi forums about the pixel doubling in 480i though as I also regularly use the pi to stream YT via VLC on my monitor, so hopefully it goes somewhere.

[vol.2]

I updated the firmware a few weeks ago to 5.10.9-v7l+, and I'm also using fkms (dtoverlay=vc4-fkms-v3d). For reference, my whole config.txt (without the comments):

Code: Select all

disable_overscan=1
dtoverlay=vc4-fkms-v3d
max_framebuffers=1
hdmi_drive=2
hdmi_group=1
hdmi_mode=6
hdmi_pixel_encoding=2
hdmi_drive=2
hdmi_force_mode=1
hdmi_force_hotplug=1
gpu_mem_256=128
gpu_mem_512=256
gpu_mem_1024=512
dtparam=audio=on

There are repeats in there, and I don't know that you have to use "force." If you duplicate a command, the last one will get passed. I would just clean that up.

Well it works fine in 240p as mentioned, but trying to set 480i is all garbled (i.e. the photo in my previous post). Maybe I'll just live with booting at 240p for ES's sake so it's at least usable.

Oh, I misunderstood you, I thought you meant that it's garbled on startup and then clears up once ES starts.

I've started a thread on the raspberry pi forums about the pixel doubling in 480i though as I also regularly use the pi to stream YT via VLC on my monitor, so hopefully it goes somewhere.

I can save you the trouble. CEA mode 6 is 720x480 in resolution, but it's sent as 1440x480 pixel doubled. It's not line-doubled though, it just sends every pixel twice during scan time, so the monitor basically only sees it as 720x480 interlaced.

Here's the modeline for CEA 6: 1440 480 60 Hz 15.7343 kHz ModeLine "720x480" 27.00 1440 1478 1602 1716 480 488 494 524 -HSync -VSync Interlace

So, it's got double the pixel clock, double the porches, double the screen time, but same field rates.

Hope that helps.

[setiawan]

I've started a thread on the raspberry pi forums about the pixel doubling in 480i though as I also regularly use the pi to stream YT via VLC on my monitor, so hopefully it goes somewhere.

I can save you the trouble. CEA mode 6 is 720x480 in resolution, but it's sent as 1440x480 pixel doubled. It's not line-doubled though, it just sends every pixel twice during scan time, so the monitor basically only sees it as 720x480 interlaced.

Here's the modeline for CEA 6: 1440 480 60 Hz 15.7343 kHz ModeLine "720x480" 27.00 1440 1478 1602 1716 480 488 494 524 -HSync -VSync Interlace

So, it's got double the pixel clock, double the porches, double the screen time, but same field rates.

Hope that helps.

Hmm it's kind of going over my head tbh. I think what I gather from your post is that, with CEA 6:

1) the system's internal resolution is still 720x480
2) the pi sends each pixel twice so it produces an image scaled 2x horizontally
3) the speeds are doubled so the 1440px lines are drawn in the time it takes to draw 720px lines, basically 1440x480 with 1:2 pixel aspect ratio

Am I close? Based on this understanding at least, it sounds like this pixel doubling shouldn't produce any visibly discernible difference compared to non pixel doubled 480i? Yet there is some visible 'pixelation' on my setup with CEA 6.

[vol.2]

1) the system's internal resolution is still 720x480

yes

2) the pi sends each pixel twice so it produces an image scaled 2x horizontally

No. It's not scaled. The pi is just sending twice the amount of pixel for each line. Your monitor doesn't care how many pixels are send per line, it just draws what it's handed. The actual resulting resolution is still limited by your monitor's maximum resolution, so you don't actually get 1440 pixels, you don't even 720 pixels, that number was chosen to enable digital to analog color conversion and it's actually kind of irrelevant.

The pixel clock is double, so it sends twice the pixels per line in the same amount of time, but it doesn't scale or change any dimensions. It's literally just sending each pixel twice, one after the other right next to each other so fast that they end up next to each other, but because each pixel was drawn twice as fast, the don't increase the length of the line and you just end up with the same image.

The reason they do this is because digital video chips tend to have a high minimum operating clock. In the digital world, keeping clock cycles in step is pretty important, and they (the ITU) planned very early on for the issues that would result with the introduction of digital video. HDMI in particular has a 25MHz minimum pixel clock, so that's why all the SDTV resolutions are double scanned. (standard pixel rate is 13MHz)

The monitor can't possibly care that you are sending it 1440x480 or 720x480. It's all the same to it.

Your resolution issues are down to the Pi not producing the correct output resolution. It's somehow picking a different H field rate (maybe 30kHz) or something weird is going on.

[Bahn Yuki]

Yes i have tried it. I have not updated pi4 firmware in a long time. Can you send me a pm with the firmware links and your ini?

Ok. I sent you the links to firmware info.

I don't know what my "ini" is. I don't have a file with that extension in my boot folder, or in my retroarch folder.

I am beginning to think that maybe your issue is also related to Lakka, if you are using that. It's pretty out of date as things have changed a lot for the Pi4 over the past year.


Also, let me be clear; I have not tried svideo with my setup. I can try maybe over the weekend, but it's not convenient for me to dismantle my equipment ATM.

Thanks for the help. After updating the kernel to latest beta firmware and getting a new dpi24 overlay I can get image with the settings from your config file in lakka. Unfortunately it's still black and white on s video. I'll try retropie tonight.

On rpi3 I get color on s video without problem. If anyone has any ideas I'll give them A shot. Even if there is a decent hdmi - svideo adapter

Sent from my SM-G970U using Tapatalk

[vol.2]

Unfortunately it's still black and white on s video. I'll try retropie tonight.

On rpi3 I get color on s video without problem.

Looking at the RTU schematic, the svideo has a dedicated chip (shared only with the composite output) that feeds it.

This is the chip: https://www.analog.com/media/en/technic ... /AD725.pdf

Two ideas that come to mind are 1) there could be something off about the timing of the chroma information, causing the color burst to occur out of screen time or 2) it's not actually working at all on the Pi3, and the only reason you see color is that the Luma trap isn't working correctly when you hook up a Pi3 and the color is bleeding through on the Luma line.

The second idea is a little far-fetched, and I don't even know if that's possible. But I thought it's just about as likely as the whole thing working on the Pi3 and not the Pi4.

It makes very little sense to me that there would be a difference. You need someone like Unseen, who really knows this stuff to take a look at the chip.

Even if there is a decent hdmi - svideo adapter

Probably your best bet. If you could find a converter based on the AD725, that would give you the same as the RTU. Then you just go Portta HDMI-VGA to a VGA-Svideo adapter. Bingo.


Also, I think I may have figured out why the svideo isn't working on the pi4. The AD725 has a maximum color info input of 714mVpkpk. I would be willing to bet that the Pi4 has higher levels than that on the color outputs!

If this is the case, perhaps some resistors at the points for Rin, Gin, Bin would solve the issue. I read some info that the AD725 is very sensitive to color level input here https://www.msx.org/forum/msx-talk/deve ... er-for-msx

[setiawan]

Your resolution issues are down to the Pi not producing the correct output resolution. It's somehow picking a different H field rate (maybe 30kHz) or something weird is going on.

Thanks for all your help vol. I've finally found a hdmi_timings that successfully outputs 480i interlaced (640x480, so 4:3 without any weird pixel aspect ratio like with 720x480), without pixel doubling!

For anyone that might have been having the same problem as me, these are the hdmi_timings I'm using:

Code: Select all

hdmi_timings=640 0 16 88 64 480 0 6 5 13 0 0 0 60 1 12700000 1

I've based the timings on a different calculator than I'd been using: https://www.epanorama.net/faq/vga2rgb/calc_v15.html

[fernan1234]

Thanks for all your help vol. I've finally found a hdmi_timings that successfully outputs 480i interlaced (640x480, so 4:3 without any weird pixel aspect ratio like with 720x480), without pixel doubling!

If this solves your problem and especially if you only need this for emulationstation then this will be perfectly fine, but it is worth noting that 720x480 is indeed the correct, industry standard for digitized standard definition video, as it did not use square pixels (the same goes for the EDTV resolution of 480p, which is correctly represented as 720x480 rather than the PC/DMT resolution of 640x480). The idea is that aspect correction can take place after digitization as needed.

A 640x480 interlaced video mode would be limiting if used for playback of SD video content, as well as for game systems (same reason why 640x240 is not ideal for "240p" all games, though it can be fine for many).

[setiawan]

If this solves your problem and especially if you only need this for emulationstation then this will be perfectly fine, but it is worth noting that 720x480 is indeed the correct, industry standard for digitized standard definition video, as it did not use square pixels (the same goes for the EDTV resolution of 480p, which is correctly represented as 720x480 rather than the PC/DMT resolution of 640x480). The idea is that aspect correction can take place after digitization as needed.

A 640x480 interlaced video mode would be limiting if used for playback of SD video content, as well as for game systems (same reason why 640x240 is not ideal for "240p" all games, though it can be fine for many).

Hmm this kind of confuses me I guess. I keep seeing this 720x480 resolution being referred to, and I don't really understand why anyone would use it in the context of a Raspberry Pi. When you say that it's the industry standard for digitized SD video, what kind of content does this usually mean? I'm currently imagining that, in practice, this refers to DVD's and maybe VCD's? So if I tried to play a DVD on some system that was outputting 640x480i, it might appear stretched a little too wide with the sides being cropped off, or letterboxed, or scaled horizontally to fit, which would create a 'correct' image but with whatever problems come with scaling.

With a rpi however, while I suppose some people might be interested in hooking it up to an optical drive to play DVD's/VCD's, I would think that the majority of people would be interested in playing more 'modern' videos, with a 1:1 PAR. At least in my use case, I'm wanting to play YT videos on it, and using the 720x480 resolution causes the picture to be slightly squished.

So I wonder, is there some benefit to using 720x480i over 640x480i on a raspberry pi, that I might be overlooking?

[Fudoh]

I'm wanting to play YT videos on it, and using the 720x480 resolution causes the picture to be slightly squished.

that comes down to a mismatch in interpretation of the signal. While 720x480 is 4:3 for your TV and it SHOULD be 4:3 for your player, obviously some players (incl yours) mistreat 720x480 as a 1.5:1 ratio.

So I wonder, is there some benefit to using 720x480i over 640x480i on a raspberry pi, that I might be overlooking?

as fernan1234 said. The only disadvantage is that you have to scale down SD video and you don't get full resolution from some games that are running in 480i natively. If it works for you, great.

I currently use standard 480i from the Pi and it bothers me that ES does also interpretate this is a 1.5:1 ratio, so all graphical objects are slightly horizontally squeezed. I'll certainly try your custom timing.

[fernan1234]

I suspect there are also some discrepancies between the how video output is produced on the Raspberry Pi (both the 4 and previously the 3) itself and how various applications (Libretro cores, different builds of EmulationStation, etc.) scale the picture and adjust various aspect ratios. And this may be specific to CRT use, since these applications in general seem to be designed for the most part for flat panel use.

using the 720x480 resolution causes the picture to be slightly squished.

If the 720x480 resolution were actually presented 1:1 or integer scale it would actually appear slightly wider than 4:3 should look. What is probably happening is that Libretro, ES, etc. are displaying only the active pixels rather than the full 720 horizontal resolution, and squeezing that into a 4:3 frame (or perhaps PAR) for the CRT picture.

I currently use standard 480i from the Pi and it bothers me that ES does also interpretate this is a 1.5:1 ratio, so all graphical objects are slightly horizontally squeezed. I'll certainly try your custom timing.

This may depend on the specific ES build. On the custom ES frontend included in the Recalbox image I use 480i actually displays with the correct aspect ratio on my CRT, and it is also displayed correctly with aspect correction enabled on Sony's pro flat panels with native scan.

[Fudoh]

This may depend on the specific ES build. On the custom ES frontend included in the Recalbox image I use 480i actually displays with the correct aspect ratio on my CRT, and it is also displayed correctly with aspect correction enabled on Sony's pro flat panes with native scan.

possibly, yes. But given that ES itself hasn't been updated in years, I wonder where the difference might come from.

On Retropie (any version of the past few years), as said, ES assumes a 720x480 output with square pixel ratio which the TV then squeezes by about 10% horizontally.

[vol.2]

AFAIK, this issue with the various components of RetroPie (the RetroPie menus, ES, the Debian menus, and the individual emulators) is exactly why Alphanu1 developed CRT switchRES.

He intended for it be usable with 15kHz displays, but he only made it as far as 31kHz displays. Hopefully he'll finish it someday, or someone else will.

If it wasn't for all the weird resolution problems with 15kHz displays and Retropie, I would have been using it long ago.

As things stand right now, Retropie on 15kHz display is like playing whack-a-mole with the various video layers.

And this is why I just use Retroarch in Debian/Raspbian. It's vanilla RA and no weird stuff. The only draw back is a few cores don't have someone updating them for ARMHf (the debian variant) like Mupen64, but you can usually find a compiled binary if you look around, or just compile yourself.

If you hate the stock RGUI for Retroarch, you can find custom color schemes and things online, and some of them are optimized for CRTs. Personally, I just use one of the color presets like Hacking the Kernel or Brogrammer and it works just fine for me.

What's important to you, staring at thumbnails of games in Emulation Station, or just having a simple and intuitive GUI that lets you quickly get into the games you want to play with zero headaches?

You can go in and change the Menu Color Theme here:

[Fudoh]

And this is why I just use Retroarch in Debian/Raspbian

I think I actually tried that, but it didn't have the physical disc support enabled. Does yours? Very hit or miss in general. Lakka for the Pi doesn't have it either (but Lakka x64 does).

[vol.2]

And this is why I just use Retroarch in Debian/Raspbian

I think I actually tried that, but it didn't have the physical disc support enabled. Does yours? Very hit or miss in general. Lakka for the Pi doesn't have it either (but Lakka x64 does).

What do you mean by "physical disc support?"

Like plugging in a USB CD-ROM drive and playing a PSX game from disc?

[Fudoh]

yes. Retroarch offcially has it since late 2019, but many distributions don't include it.

[vol.2]

yes. Retroarch offcially has it since late 2019, but many distributions don't include it.

I have never even though about it.

I'd try it out for you, but I don't actually own an external CD-ROM drive.

FWIW, I can't imagine it would be an issue. You would just have to mount the CDROM in Raspbian and turn it into a physical location. At that point, Retroarch should just see the drive as any other drive and load or not load. Debian is what takes care of the CDROM on a device level. But I don't want to eat my words, maybe there is some bug that makes it not work or something.

[Fudoh]

As said, I tried this. With almost every retroarch distribution available, on many different hardware platforms and the guys in charge of compiling the ARM builds don't consider this an important feature, so it's hard to find.

[vol.2]

As said, I tried this. With almost every retroarch distribution available, on many different hardware platforms and the guys in charge of compiling the ARM builds don't consider this an important feature, so it's hard to find.

My guess is that Lakka just doesn't work because they didn't pre-bake an automated CDROM mount into the setup procedure. It's slightly different from the command-line, so it would be an extra step. Even for an SSD, you have to do that part separately (find the UUID and set it as a boot device in the cmdline.txt).


Here's an article on using CD-ROM drives with a Pi. https://magpi.raspberrypi.org/articles/ ... om-console

[Fudoh]

Code: Select all

hdmi_timings=640 0 16 88 64 480 0 6 5 13 0 0 0 60 1 12700000 1

unfortunately incompatible with my displays over HDMI, which makes it a pain to use. Having a timing available (CEA6) that works flawlessly on both, HDMI displays and CRTs, makes it so much easier to switch around. Just create multiple config.txt and videomodes.cfg files and have them swapped out by running a script.

[setiawan]

Anyone know what the minimum pixel clock on a Pi 4 is?

Trying to get 320x200 or 320x240 to work for Dosbox. I can pass that resolution through, but I have massive horizontal borders because the blanking time is so long. When I try to reduce the blanking any further, which brings down the pixel clock, the pi just doesn't put out a picture anymore. That's once I dip below around 9.8MHz.

I hear that what pixel clocks are valid are a function of the oscillator frequency, specifically it has to be an integer division of the osc frequency (for Pi 4 B that's 54MHz). Even when I try 6.75MHz though (54 divided by , I get no picture..

I can get 640x240p to show up pretty well on the CRT, which would have been fine if I could get Dosbox to scale horizontally 2x, but it's starting to look like that you can't do that in Dosbox.

[vol.2]

Anyone know what the minimum pixel clock on a Pi 4 is?

I think it's around 6MHz, but that isn't going to be an issue for you. You are running into HDMI problems, not Pi pixel clock problems. I can run 320x240 over the GPIO no problem whatsoever.

There's 2 or 3 things I can think of that might be screwing you up.

- The HDMI minimum pixel clock is 25MHz by spec, so your controller isn't obligated to handle anything below that (though it might do so). This, by the way, is one of the reason that modes CEA6 and 8 exist; the CEA and VESA knew that higher pixel clocks would be necessary for digital video (both for color space conversion and for clock cycle requirements) and they created standard modes that increased the pixel clock by issuing pixels in multiples.

- The Pi4 itself sends 2 pixels per clock cycle, so ALL pixel groupings must be an even positive integer value. That means everything, including the sync pulse and the clock. No odd number values anywhere in the modeline anywhere.

-Whatever mode line you are creating just isn't supported by your HDMI-VGA adapter. Most of them optimized for specific video modes, and were never really intended to pass random modelines. You might be hitting the limits of something, or there is some resolution binning process that rejects it.

[setiawan]

- The HDMI minimum pixel clock is 25MHz by spec, so your controller isn't obligated to handle anything below that (though it might do so). This, by the way, is one of the reason that modes CEA6 and 8 exist; the CEA and VESA knew that higher pixel clocks would be necessary for digital video (both for color space conversion and for clock cycle requirements) and they created standard modes that increased the pixel clock by issuing pixels in multiples.

Although the controller isn't obligated to do so, I wonder if it'd be possible to find out what that lower limit is. I've asked over at the raspberry pi forums, but I don't have high hopes that I'll get a very informative response. I've been able to pass through the equivalent resolution with pixel doubling, but it comes out weird. Like there are gaps between each doubled pixel. Not sure what's up with that. It's otherwise a stable image:

- The Pi4 itself sends 2 pixels per clock cycle, so ALL pixel groupings must be an even positive integer value. That means everything, including the sync pulse and the clock. No odd number values anywhere in the modeline anywhere.

Can confirm all the values in the timings tried are even, so not that.

-Whatever mode line you are creating just isn't supported by your HDMI-VGA adapter. Most of them optimized for specific video modes, and were never really intended to pass random modelines. You might be hitting the limits of something, or there is some resolution binning process that rejects it.

Could be that I guess. I'm using the Portta, and it's been pretty good at handling some of the pretty arbitrary resolutions I've been throwing at it, but I guess it could also have its own lower limit.