DIY Pitot tube

[kfong]

I'm interested in building a pitot tube to measure onboard speed. I'm unfamiliar on how to implement the mechanics of such a device, from what I've gathered so far it requires a differential pressure sensor to compare dynamic (forward air pressure) and static (air pressure at right angle to the tube). I assume it requires 2 tubes, one facing forward and away from any prop wash, and one at right angles to the air flow. Has anyone found a good air pressure sensor to use for this application and any formulas I could use. I plan to implement a pic based system to measure the speed. I read that true airspeed, one must also take account of temperature as well. Any pictures of the physical setup would be appreciated.

Kin


http://www.embeddedtronics.com/

[LukeZ]

Kin, I have successfully measured airspeed using a Freescale MPX5010 differential pressure sensor and a PIC. I do not yet have all the information and formulas on my website for this yet, but I do have altitude information posted. Some of the formulas are relevant for both calculations.

Look at my Altimeter Links page (http://www.kansasflyer.org/index.asp?nav=Avi&sec=Alti&tab=Theory&pg=7) and go to the bottom one - Wahiduddin's page (http://wahiduddin.net/calc/density_altitude.htm). He has a lot of good info on density altitude calculations that are relevant to airspeed measurements.

Sorry I don't have more info for you - I plan to post a tutorial for airspeed theory that goes into as much detail as my altitude tutorial, but I just haven't had the time.

I'm sure others on this forum will have some helpful advice for you as well.


Luke

[kfong]

Hi Luke,

Was it the MPXV5010DP sensor, that one looks like the smallest they carry with dual ports for the pitot. If I were to measure altitude as well, I would require one more sensor, or do you think there is a way to combine them. I think not but best to bring up the subject. Thanks for the help, this at least gets me started on the design.

Kin

http://www.embeddedtronics.com/

[LukeZ]

Kin,

Yes, the V5010DP will work - I used the 5010DP (no "v") which is slightly larger in size but they're the same.

You're right, if you want to measure altitude as well you will need another sensor - an absolute sensor I use the MPX4115 as you can see on my site. However, the static port of the differential sensor and the single port of the absolute sensor could be tied together with the same tubing (assuming you want to use tubing). This is because they will both be measuring the same thing: ambient pressure.

For this reason it is possible to do altitude and airspeed using two absolute sensors and no diff sensor. One measures static pressure, the other measures pitot pressure. The static pressure is used for altitude calculations. Then in code you take the difference between that and the pitot pressure to arrive at airspeed.

However, you're still using two sensors - also you'll have a slight bit more of code and depending on the resolution you want for your altimeter, you may end up with more circuitry. For that reason I personally feel it's just easier to do as you suggest - use a diff sensor for airspeed and a separate absolute sensor for altitude. They're about the same price so you won't be saving anything either way (at least if you go with Freescale sensors).

Speaking of price - Freescale has a samples program and you can probably get both sensors for free. I know I have. It seems to me they also are willing to ship overseas, if that's an issue - but it looks like you're located in Michigan.


Luke

[kfong]

Thanks, I like the idea of using the same pitot tube and use of dual sensors. Resolution is a concern so I will go with a differential and a absolute to start out with. They have the same footprint as well which is nice. I have both on order. The pic I will be using has 10bits of resolution, do you think this will be enough?

As far as physically putting together the system, I assume you can use surgical tubing, I will test this on a stryker so I will put the pitot near the front. As far as the static tube, how would I impliment that part of it, I've know it needs to be next to the pitot for accuracy, but do you bend it at a right angle to the wind. I also assume both static and pitot pressure must use the same size diameter tubing.

One of the members pm me and said they use a tube within a tube and just have a hole on the side for the static pressure and have the end capped off, but this seems more complex to implemement.

Kin

http://www.embeddedtronics.com/

Kin,

Yes, the V5010DP will work - I used the 5010DP (no "v") which is slightly larger in size but they're the same.

You're right, if you want to measure altitude as well you will need another sensor - an absolute sensor I use the MPX4115 as you can see on my site. However, the static port of the differential sensor and the single port of the absolute sensor could be tied together with the same tubing (assuming you want to use tubing). This is because they will both be measuring the same thing: ambient pressure.

For this reason it is possible to do altitude and airspeed using two absolute sensors and no diff sensor. One measures static pressure, the other measures pitot pressure. The static pressure is used for altitude calculations. Then in code you take the difference between that and the pitot pressure to arrive at airspeed.

However, you're still using two sensors - also you'll have a slight bit more of code and depending on the resolution you want for your altimeter, you may end up with more circuitry. For that reason I personally feel it's just easier to do as you suggest - use a diff sensor for airspeed and a separate absolute sensor for altitude. They're about the same price so you won't be saving anything either way (at least if you go with Freescale sensors).

Speaking of price - Freescale has a samples program and you can probably get both sensors for free. I know I have. It seems to me they also are willing to ship overseas, if that's an issue - but it looks like you're located in Michigan.


Luke

[jeffs555]

For this reason it is possible to do altitude and airspeed using two absolute sensors and no diff sensor.

This is possible, but much better to use differential for airspeed. Unless the two absolute sensors track each other perfectly, you can get significant errors.

[LukeZ]

Jeff - I agree with you, I was just pointing out the possibility.

Kin, surgical tubing or model RC fuel tubing is fine. I'm not sure that if you use two separate tubes that it really matters all that much if they are of the same diameter, but it wouldn't hurt. At any rate the nipples on the sensors are going to be the same size so it makes sense to use similar diameter tubing.

There is nothing that says you have to have the static port near the pitot tube. On many full sized aircraft they are in completely different locations. Single engine Cessnas I have seen typically put the static port on the side of the fuse near the aft of the craft, close to the tail. This is to get as far away from the turbulence of propwash as possible. However, in many instances the static port will be built into the pitot tube (then it's called a pitot-static tube). The reason is, I suppose, because the pitot tube typically points out into undisturbed oncoming air, and this is the kind of air you want for the static port as well. However, you are right, the pitot tube points into the oncoming air, whereas the static port must exit perpendicular to the oncoming ari (90 degrees). A tube within a tube can be used. This is sometimes hard to visualize, but this site (http://www.efunda.com/designstandards/sensors/pitot_tubes/pitot_tubes_theory.cfm) has a picture that gives the general idea.

Or, you could use two seperate tubes instead of a tube within a tube. I've attached some pics below that hopefully help. So you have several options.

Now, as for your resolution - 10 bits isn't going to be much when it comes to altitude, but it should be ok for airspeed. If you want to read the nightmare adventures of increasing resolution for altitude, I'd point you to this thread (http://www.rcgroups.com/forums/showthread.php?t=372869), which chronicles my adventures in this very area, and even includes schematics. It's been a while since I posted but I'm back on the project and I intend to revive the discussion there soon.

If you don't intend to go very high, 10 bits may be fine - although the altitude sensor will work to very high altitudes, you could just scale the output so that your A/D converter only sees the first 1000 feet or so. Then you'd have a resolution of 1 foot. But if you want to measure higher than that and maintain small bits of resolution, then you're going to need a better A/D (I'm using a 12 bit) or dynamic scaling (which I'm also doing - I want ~1 foot resolution up to 45,000 feet). Either way you're in for a bit of work.


Luke

[brnjones]

LukeZ, did you buy that pitot-static tube hardware, or make it yourself? Are there any sources of information for designing/building pitot tubes for RC aircraft?

-Brandon

[LukeZ]

Brandon, I'm sorry I gave the wrong impression: I didn't make those pitot tubes, or even know who did. I just found the images by searching the net, and posted them for illustrative purposes. At any rate they're for full sized-aircraft so probably would be too heavy for most of our purposes.

I don't know of any sources for designing/building your own, specifically for RC aircraft use - and if anyone does I'd be just as interested in seeing it. Maybe someone will post here.

But it's my impression that most people just make these themselves out of metal tubing that you can get at the hobby shop - brass or aluminum or steel even if you wanted. The pitot tube is easy: just point the tube into the wind. The static tube is pretty much just as easy: seal off the end of the tube that faces into the oncoming airstream, and drill small holes along the shaft. Attach some surgical tubing between the tubes and your sensors, and there you go.

The tube that actually is a bit tricky to make, as I understand it, is the one used in variometers. And if anyone has more info on that I'd be real interested to see it as well.


Luke

[kfong]

Hi Luke, looks like I'll be following your footsteps. Interesting where all this is taking me, sure is getting complicated fast. TOTAL ENERGY PROBE article on how to make one for a real glider http://www.wcsa.org/docs/TEprobe.pdf. It had not even occur to me about sink rates and it's effects on altimeter readings. I'm playing catch up at the moment. I find your website very informative, will be making a circuit board. Maybe we can coordinate it. Not sure how much time I can devote to this project, too many on my list, but will eventually see it thru.

Kin

http://www.embeddedtronics.com/

[brnjones]

kfong--
Awesome article.
Thanks!

[LukeZ]

Kin, that was a good article about the TE probe, thanks for posting it. Although I'm still not entirely certain how I would implement a vario with a pressure sensor: what would one do for the "flask"? I suppose this could probably be a different thread altogether...

Yes, it does all get very complicated pretty quickly, if you want something that is precise, accurate, and has a wide working span (both in terms of altitude and temperature). However I find that the altimer is much the more difficult circuit to do, airspeed is relatively trivial from a hardware point of view (unless you want to go Mach 3 for some reason). The formulas for airspeed can get pretty complicated though, especially if you want to accurately calculate air density - I guess I really need to post that section of my site soon.

What circuit board are you going to make? If you meant the one on my site I'd just caution that it's fairly basic - in fact it was my first attempt at PCB design. The circuit is not incredibly advanced, and is useful mostly just for testing the principles but probably not much else. The resolution is pretty poor, I think something on the order of 7 feet at sea level, and less as one gets higher, as I did no amplification of the signal. The AD chip I used is a bit expensive also, but you can get free samples from Linear.

I've had your site bookmarked for quite some time now - you have some good circuits and clearly a lot of experience in this area. I did not realize you were also an eZoner until you posted here. If you make a board I'm certain it will be a good one. When my version 2 is completed (who knows when) I'd really like to have it all be done in surface mount components - perhaps we could coordinate. I've never done SMT before and it seems a bit daunting, especially if you were to see the size of my soldering iron tip! :eek: (just a cheapo I bought at Radio Snack.) But you seem to have that down pretty good.

Please keep me posted on your progress, I'm very interested to hear about other people's experiences along this same path. You may also want to post over in the other thread (http://www.rcgroups.com/forums/showthread.php?t=372869) that discusses op-amps for scaling of the altimeter output as well, depending.


Luke

[kfong]

Hi Luke,

I was thinking the flask isn't needed since we are using solid state sensors. I was under the impression that the setup they had were the older style mechanical stuff. The total energy probe does most of the work of giving the sensor a static pressure reading was the way I interpreted it, since it creates a vacuum under certain conditions stabilizing the total static pressure, but I could be wrong.

I'm just at the beginning stages of creating an on board telemetry system so I want to incorporate as much as I can. It will probably be in stages, long term project. Just a lot of other projects and interests that keep me busy. I tend to jump around to what keeps my interest. I'm information gathering at the moment, but if I see a circuit that looks ok, I will usually get a circuit board made to test it out. I haven't had a chance to go through the thread or cover what you have already done.

I do plan to make a quick board, pic base with the sensors soon so what ever I come up with will be thrown in. I don't bother with proto board wiring, faster for me to just make up a circuit board test it and incorporate it later in a final design.

Kin

http://www.embeddedtronics.com/

[LukeZ]

Kin, yes I think you're right about the flask. I suppose one would need to use a vacuum sensor of some sort - or differential sensor perhaps as shown in Figure 8 of your document - simply have the dynamic side attached to the static line, and the static side attached to the TE probe. This would essentially be your vario, and would allow you to measure "vacuum" (really, just a difference). The rest of the work would be done in software. But I think I need to do some more reading on this.

At any rate the vario stuff and total energy compensation is not really related to altitude; one loses altitude if they dive or sink either way, and the altimeter will still read that (unless the mass of air you happen to sink in remains the same pressure - but even then, a TE probe isn't going to help you measure your geographic altitude any better). I'm interested in the vario however, because someday I'd like to write a program that allows the plane to autonomously find lift and avoid sink - an automatic thermaler if you like.


Luke

[kfong]

Yes, I'm interested in the TE, or else I could just use a absolute sensor for altitude and be done with it. I like to fly gliders as well and had not thought much of the problem until you brought it up. I should be getting the sensors soon, but need to get my butt in gear so I have pc boards to test them on.

Kin

http://www.embeddedtronics.com/

[kfong]

I came up with a circuit, it will be sent out tomorrow afternoon at the latest. Sorry for such short notice. Let me know if I should add anything or any comments.

Kin

http://www.embeddedtronics.com/

[HLGNut]

Here's a site that might have what you are looking for:

http://www.cleanair.com/Equipment/Express/pitot-std.htm

There are a couiple of telemetry systems out there:

http://www.rcatsystems.com/index.php
http://www.gpsflight.com/

that use a simple brass tube for the pitot tube and ambient air around the sensor for the static.

In regards to TEK probes there are two modeling systems that have probes. You can find them at:

http://www.renschler.de/eng/pages/produkte_e/frmprod1_e.html (look at Picolario)

or the US rep: http://www.picolario-usa.com/

and

http://www.tek-variometer.de/englisch/index.html

We use the Picolario with TEK probe in our cross county ship and it indeed helps.

Cheers,

- Bob -

[Mr.RC-CAM]

I came up with a circuit, it will be sent out tomorrow afternoon at the latest. I definitely will be interested in how the AD7714 performs for you (looks like a nice part). It will take a serious PCB layout (faultless grounds and signal guarding) if you need all 24 bits. :) The output at the plug looks like you intend to create a non-overlayed video signal. Is that what you will be doing?

Overall, looks like fun.

[LukeZ]

Kin -

I see you're going with a 24 bit AD - you shouldn't have any problem with resolution using that approach.

Your circuit looks fine. The only thing I'd add is a small RC filter on the output of the two pressure sensors. This is detailed in a Freescale app note, which I've attached.

Luke

[kfong]

I definitely will be interested in how the AD7714 performs for you (looks like a nice part). It will take a serious PCB layout (faultless grounds and signal guarding) if you need all 24 bits. :) The output at the plug looks like you intend to create a non-overlayed video signal. Is that what you will be doing?

Overall, looks like fun.

Yep video. The software will be the big stumbling block for me. I'm really more of a hardware guy. Noise will be a problem, going with 2 layers if possible, so it will be interesting if the 24bits work out without a good ground plane.

Kin

http://www.embeddedtronics.com/

[Mr.RC-CAM]

Yep video. The software will be the big stumbling block for me.You might want to add one more PIC control line to the base of the video driver transistor. Normally tri-stated, it would be used to force a black level whenever you talk to your EEPROM. Otherwise, you will get unwanted video pixels when you read/write data to it.

Video generation is all about precise timing. All your altitude computations will need to be done inside the video blanking period or during unused horizontal lines. Stick with integer math, pay attention to code overhead, avoid interrupts, and you will be fine.

Noise will be a problem, going with 2 layers if possible, so it will be interesting if the 24bits work out without a good ground plane. I suspect you will be only achieve about 14-bits above the noise floor without going to a very carefully designed multilayer board with dedicated power and ground planes. But, that should be plenty, especially since your A/D has programmable gain for useful scaling.

[kfong]

Thanks, didn't catch that, here is the latest. Might as well use up the rest of the channels. Any thoughts on that?

Kin

http://www.embeddedtronics.com/

Kin -

I see you're going with a 24 bit AD - you shouldn't have any problem with resolution using that approach.

Your circuit looks fine. The only thing I'd add is a small RC filter on the output of the two pressure sensors. This is detailed in a Freescale app note, which I've attached.

Luke

[LukeZ]

Yes, I think you might as well bring out the other inputs to a header - never know what else you might want on there. I'm getting ready to wire up a Honeywell humidity sensor for example - can't remember exactly what part number but I believe it's in the 3610 series. Wouldn't need 24 bits on that for sure, but at any rate it just goes to show you never know what else you'll want to add. Angle of attack is another one that comes to mind...

Have you used the LM34 before? I'd be interested to hear your experience with them. I've been using the Dallas DS18S20 1-wire temp sensors. They work well but can take a lot of extra work (coding) to set up, especially if you want to be able to swap sensors in and out (it has to run through a search routine to identify them, etc...)

Keep us posted - I too will be curious about your experience with the AD chip. But even if you only get 14 bits your resolution should be in the range of 2-3 feet near sea level, which is pretty good.


Luke

[kfong]

Don't get you hopes up too high, I tend to make the boards quite fast but let it sit for a while. A/D chip is ordered. Software just takes too much time. If I get some down time then I will go at it. My brother is really the software guy on our site, but he has no interest in RC and I have too many interests.

Kin

http://www.embeddedtronics.com/

Yes, I think you might as well bring out the other inputs to a header - never know what else you might want on there. I'm getting ready to wire up a Honeywell humidity sensor for example - can't remember exactly what part number but I believe it's in the 3610 series. Wouldn't need 24 bits on that for sure, but at any rate it just goes to show you never know what else you'll want to add. Angle of attack is another one that comes to mind...

Have you used the LM34 before? I'd be interested to hear your experience with them. I've been using the Dallas DS18S20 1-wire temp sensors. They work well but can take a lot of extra work (coding) to set up, especially if you want to be able to swap sensors in and out (it has to run through a search routine to identify them, etc...)

Keep us posted - I too will be curious about your experience with the AD chip. But even if you only get 14 bits your resolution should be in the range of 2-3 feet near sea level, which is pretty good.


Luke

[kfong]

Can you elaborate a little more on that, the circuit was taken from one of the pic video circuits. Can't recall where.

It's been a while since I've been on your site. I found this to be really interesting. I have most of the parts. Got any more boards? What's the dimensions?
A/P Camera Controller, with Wireless On-Screen-Display (OSD)

Kin

http://www.embeddedtronics.com/

You might want to add one more PIC control line to the base of the video driver transistor. Normally tri-stated, it would be used to force a black level whenever you talk to your EEPROM. Otherwise, you will get unwanted video pixels when you read/write data to it.

Video generation is all about precise timing. All your altitude computations will need to be done inside the video blanking period or during unused horizontal lines. Stick with integer math, pay attention to code overhead, avoid interrupts, and you will be fine.

I suspect you will be only achieve about 14-bits above the noise floor without going to a very carefully designed multilayer board with dedicated power and ground planes. But, that should be plenty, especially since your A/D has programmable gain for useful scaling.

[Mr.RC-CAM]

Can you elaborate a little more on that, the circuit was taken from one of the pic video circuits. Can't recall where. {Note: I have to sort of guess at what you have planned for your video generation routines. You may have all of this already covered (there are many ways to skin cats), so please excuse me if I missed that.}

One of your video control lines is shared with the E2Prom. So, if you should R/W to the E2Prom *without careful planning*, the video will probably display some random-looking pixels during the E2Prom R/W'ing.

You can avoid extra hardware if your application is able to R/W to the E2Prom during the unused horiz scan lines (not all 525 lines are visible). If you are not sure if this will be possible, then you can buy yourself a backup plan by adding an extra control line to base of the video transistor (perhaps with a 1K resistor in series). The control line would normally be tri-stated. Force it low to clamp the video off if you will be R/W'ing during active video scan lines.

[JimDrew]

Several of the original "Pong" type video games used tricks like this. You can do a search on the net for "pong" and "PIC", and you will see a bunch of links to various code and hardware schematics. Now days, people are using the Scenix chips to get full color and sound generation. Pretty neat stuff. Also, remember, there is a difference in the rasters for PAL and NTSC.

[kfong]

Good point, found a spare pin so I threw it in. Final board and what the board looks like. I'm avoiding smt if possible so it's not as compact as I like, but not bad. Dimensions are 2.4" x 1.6". I was able to flood the top with a ground plane, this should help reduce the noise somewhat. I should have the boards in my hands in about a week.

Thanks for the help guys,

Kin

http://www.embeddedtronics.com/

{Note: I have to sort of guess at what you have planned for your video generation routines. You may have all of this already covered (there are many ways to skin cats), so please excuse me if I missed that.}

One of your video control lines is shared with the E2Prom. So, if you should R/W to the E2Prom *without careful planning*, the video will probably display some random-looking pixels during the E2Prom R/W'ing.

You can avoid extra hardware if your application is able to R/W to the E2Prom during the unused horiz scan lines (not all 525 lines are visible). If you are not sure if this will be possible, then you can buy yourself a backup plan by adding an extra control line to base of the video transistor (perhaps with a 1K resistor in series). The control line would normally be tri-stated. Force it low to clamp the video off if you will be R/W'ing during active video scan lines.

[brnjones]

I noticed that Eagle Tree Systems has a "extra pitot tube" item for $4.99. There isn't a picture or anything. I wonder if it would be useful.....

http://www.eagletreesystems.com/Sailplane/sailplane.html

[Acetronics]

Hi, brnjones

a quick look at the manual shows what is called "pitot" is just a stupid piece of brass or alu. tubing ...

5 bucks for that ??? joking, I hope !!!

Alain

[deh6]

I'm a late-comer to this thread. A couple of thoughts on this thread--

Airspeed--
Calculating true airspeed from indicated airspeed is useful for navigation, e.g. time * speed = distance. How the plane flies, e.g. stall speed, depends on indicated airspeed so there is no need to make the calculation to compensate for air density.

Total energy--
The TE probe provides a static source to the variometer so that the vario doesn't follow dives and pullups. As a result the vario shows a glider pilot the true lift as he/she enters a thermal even though the stick may be pulled back (converting kinetic energy into altitude).

Some years ago I flew sailplanes (fullsized) and we used Braunswcheig tubes for the static source for the vario. It is a closed off tube bent 90 degrees with several slots cut into the trailling edge. It looked similar to the one in the following url--
http://www.tek-variometer.de/englisch/index.html

An even earlier scheme used a diaphragm/valve arrangement that connected to the pitot tube and static source and fed the vario with a compensated pressure--much more complicated and expensive than the simple Braunswcheig tube. This was all before microprocessors became powerful & cheap.

My thinking for model airplanes is to do the total energy computation in the micro, using the pitot-static pressure as the input. One should be able to add some calibration points so that the compensation is improved. The basic scheme is based on the kinetic energy being proportional to the square of the speed and the polar of the plane is parabolic. With the newer high performance airfoils the polar departs a little from parabolic so that the basic TE compensation is not perfect (but vastly better than none).

Altimeter--
Intersema Sensoric, MS5534A has an interesting part--

http://www.intersema.ch/site/technical/ms5534.php

It is 27.15 Swiss France, about $20US, and has a built in 15 bit ADC. The shipping on samples is 30 Swiss Franc which doubles the price to the door (for one unit).

Given the trouble and cost of what needs to be added to get good resolution on the Freescale parts, the cost may well be worth it.

[mluvara]

http://www.rcatsystems.com/index.php

that use a simple brass tube for the pitot tube and ambient air around the sensor for the static.


FYI - The rcats unit does not use a simple brass pitot tube. We have a very precise combined pitot-static probe that is designed for giving good measurements. Using ambient static inside a fuselage is not very accurate at all and in the majority of cases, will skew your data one way or the other and is dependent on aircraft speed/attitude,etc.

http://www.rcatsystems.com/accessories/pitotprobes.php

Michael
RCATS

[kfong]

Finally got the boards and had some time to stuff it. So far it looks good. Now comes the programming part. It will be a while, anyone interested in one of these boards let me know, based on this design http://www.kapelec.com/altivie1.htm

Kin

http://www.embeddedtronics.com/

[rocky79]

Looking at this thread posts on the Pitot tube. I didn't see any specific measurements for length of the tube the width of the static holes and the tube bend radius.Any information on how to choose those parameter?
Thanks

[rsosa]

Looking at this thread posts on the Pitot tube. I didn't see any specific measurements for length of the tube the width of the static holes and the tube bend radius.Any information on how to choose those parameter?
Thanks

That is exactly what i am looking for... any hint much appreciated

[AndyKunz]

I definitely will be interested in how the AD7714 performs for you (looks like a nice part). It will take a serious PCB layout (faultless grounds and signal guarding) if you need all 24 bits.

We did one with it shooting for 22 bits, and grounding was a MAJOR issue. It does work as advertised, providing you get the layout right. We spent a lot of time on the phone to the chip design team trying to get it resolved. Eventually we cancelled the product.

We're using an MCP3551 now on a related product and having far less trouble all around. Not as capable, but 18+ bits of precision was easy. Getting test equipment just as accurate was fun - company politics :(

Andy

[sguty]

Looking at this thread posts on the Pitot tube. I didn't see any specific measurements for length of the tube the width of the static holes and the tube bend radius.Any information on how to choose those parameter?
Thanks

There was another thread that had a link to a german site (http://home.germany.net/100-173822/d_logger.htm) which had a relative-dimensioned pitot tube, didn't talk about your specific parameters, but I think the dimensions noted are the critical ones.: