SUBSIM Radio Room Forums

SUBSIM Radio Room Forums (https://www.subsim.com/radioroom/index.php)
-   Dangerous Waters (https://www.subsim.com/radioroom/forumdisplay.php?f=181)
-   -   Broadband vs narrowband sonar (https://www.subsim.com/radioroom/showthread.php?t=145539)

Dr.Sid 12-18-08 04:23 AM

Main difference compared to DW is the delays induced by finite sound speed will be correctly simulated, to such extent, that it alone will allow active sonar simulation.
Each sound will 'travel' and 'hit' other platforms in correct order, where it will get detected (for passive) or bounced (read new sound event will be generated) for active sonar. This is general mechanism how sound will get from source to listener.

This is actually what I'm working on in the moment.

As for transmission loss, layers, channels and so on, nothing like raytracing is possible because of huge amount of computing it needs, so it will be just lookup tables based on range, depth of listener, depth of target. However I plan to have these changing fluently with daytime and location. I'd also like to have let's say 3 frequency ranges so different frequencies can react differently on sound speed profile.

As for sound source, it's clear DW's 4 constant lines per platform is huge simplification, and I plan to have quite complex sound sources, since it's cheap. So there will be many components, each related to expected cause, and variable not only in amplitude, but in frequency too, where it should be. Propeler noise, flow noise, gear whine, pumps, steam noises, generators, you name it. And of course, correctly simulated transients, which will generaly be samples played (and heard on listener side) when some specific event happens (like torpedo tube opened, or coin dropped :rotfl:).
This will make identification much harder and description of sub wont be 4 frequencies. Expect long process of guessing and ruling out. You should be able to tell 'this is ruskie sub' quite soon, while it might be hard to tell if it's delta III or delta IV. Anyway this rich possibilities will easily allow each hull to be slightly different.

As for listener side gear, it will just look slightly more complicated, there is nothing much wrong with it in DW, except it's simplistic at some details.

Of course there will also be MUCH more false contacts, and there will be better environment simulation.

XabbaRus 12-18-08 05:08 AM

Sounds good Sid,

I have a week and a half off over Christmas....so I'll send you some more subs.

If you can let me know what happens with the surface models where they go weird on you I could try and mitigate it in the model before I send it.

I'd like to make a big push with this and get you some nice surface vessels.

Dr.Sid 12-18-08 06:20 AM

Hopefully I get more time over Christmas so I'd like to find those 3ds bugs. Most probably I just ignore some sections which did not appear earlier.

XabbaRus 12-18-08 07:14 AM

It's odd as they work in DW fine after being converted to J3D.

I'd have thought if there was a problem with the model DW would have shown it up.

Dr.Sid 12-18-08 07:42 AM

There for sure is no 'problem' with those files. They just use some feature I don't support at the moment.

Deamon 12-18-08 02:22 PM

Quote:

Originally Posted by Dr.Sid
Main difference compared to DW is the delays induced by finite sound speed will be correctly simulated, to such extent, that it alone will allow active sonar simulation.
Each sound will 'travel' and 'hit' other platforms in correct order, where it will get detected (for passive) or bounced (read new sound event will be generated) for active sonar. This is general mechanism how sound will get from source to listener.

This is actually what I'm working on in the moment.

As for transmission loss, layers, channels and so on, nothing like raytracing is possible because of huge amount of computing it needs, so it will be just lookup tables based on range, depth of listener, depth of target. However I plan to have these changing fluently with daytime and location. I'd also like to have let's say 3 frequency ranges so different frequencies can react differently on sound speed profile.

As for sound source, it's clear DW's 4 constant lines per platform is huge simplification, and I plan to have quite complex sound sources, since it's cheap. So there will be many components, each related to expected cause, and variable not only in amplitude, but in frequency too, where it should be. Propeler noise, flow noise, gear whine, pumps, steam noises, generators, you name it. And of course, correctly simulated transients, which will generaly be samples played (and heard on listener side) when some specific event happens (like torpedo tube opened, or coin dropped :rotfl:).
This will make identification much harder and description of sub wont be 4 frequencies. Expect long process of guessing and ruling out. You should be able to tell 'this is ruskie sub' quite soon, while it might be hard to tell if it's delta III or delta IV. Anyway this rich possibilities will easily allow each hull to be slightly different.

As for listener side gear, it will just look slightly more complicated, there is nothing much wrong with it in DW, except it's simplistic at some details.

Of course there will also be MUCH more false contacts, and there will be better environment simulation.

Good stuff Dr.Sid. I am curious how much of this stuff you will be able to pull out. I planed to do the same back in the days for my cold war project before I switched to WWI. But even for my WWI sim, I still want to do it.

Dr.Sid 12-18-08 03:11 PM

That's actually why I like modern subs .. because you can play with sonar so much :arrgh!:

SeaQueen 12-20-08 11:37 AM

Quote:

Originally Posted by Bubblehead Nuke
I have chatted with Dr. Sid about that very thing. As long as the CONCEPTS are fundementaly correct, who cares about the exact numbers.

That's so true. One of my pet peeves of naval simulations is how people obsess over all the techno-weenie details and end up missing the big picture. A good wargame should be about tactics and decisions. Details of specific numbers and knob twiddling should be secondary. They really only need to be in the ballpark because often the uncertainty on actual numbers is large and the impact of that uncertainty dwarfs the importance in terms of decisions than whether a given platform's source level at 138Hz is 120dB or 135dB.

SeaQueen 12-20-08 11:46 AM

Dr. Sid, how do you plan to do better environment simulation and false contacts?

Dr.Sid 12-20-08 04:13 PM

Honestly I don't know much yet. I did not discuss this much with anyone.

By environment I mean background noise. This seems to be covered quite well in Urick, and there is no technical problem (I know of).

As for false targets .. there should be more bio targets, rocks, ice peaks or wrecks, all with both passive (water flow and eddies for silent ones) and active, and magnetic and so on when we get there.

Also for active the bottom reflection should be made better I think, especially if it's rocky, there should be a chance to hide at the bottom (I guess).

Any comments are appreciated.

Shadowmind 12-20-08 09:43 PM

Dr. Sid, I agree with all of your ideas for more realistic sonar environment. A few interesting items, would be the ability to detect other contacts from the reflections from other vessels active sonar emissions. I wouldn't expect a real accurate range based on the fact that the ownship wouldn't know the exact time the active pulse was transmitted, but you should be able to at least detect reflections and get a bearing.

You mentioned you wanted to use ray tracing, but it is too expensive. Maybe there are some optimizations/compromises that can be made. For example, only perform the ray-tracing from a noise source to ships that may be listening. For example, if there is a sub X nm from the noise source, but the sub is traveling too fast to pick up the signal, then you could optimize that ray away.

I know NVidia did a demo recently of a real time ray traced scene. I don't recall the resolution, but it was higher than 1280x1024. Although I believe that was on a quad GPU setup.

I guess my point is, it would be nice to built the engine with the ability to support ray tracing and a table based system. If you can't hit the performance goals on a certain platform, you fall back to the table based system. But if you have a powerful enough system, you could use the ray tracing scheme.

Dr.Sid 12-21-08 05:43 AM

There is absolutely no need for raytracing in the first place. It would not be better then the tables, since the tables itself would be based on raytracing. But raytracing alone is only valid for high frequencies and idealistic conditions. It's also good for estimating convergence zone range for example, and there could be such tool accessible from sonar station, but generaly it's only one solution for part of the problem.

Here I have to take all phenomemons I want to simulate, and find best approach.

Also realtime is not enough, since we want to use time compression, and lot of it.
And 'every listening platform' may be array of 50 sonobuoys .. the sonar really has to be done as fast as possible.

Look at DW . .even on my core duo 2.3 GHz it mostly does not manage to go 32x, if there is more platforms, and it fakes sonar in great way, especially for AI.

Deamon 12-21-08 11:57 AM

Quote:

Originally Posted by Dr.Sid
Also for active the bottom reflection should be made better I think, especially if it's rocky, there should be a chance to hide at the bottom (I guess).

Any comments are appreciated.

I have read in a WWII u-boat book about one occasion in the norwegian sea where a british destroyer come close to the u-boat while pinging but the commander of the u-boat wasn't concerned about it at all cause the bottom was rocky and the depth was shallow, iirc, indicating that his asdic was useless cause it gets echos from everywhere on the bottom.

SeaQueen 12-23-08 07:37 AM

There are technical problems in terms of getting data. Even though theoretically we know how to model it to some reasonable approximation, the next question is, which numbers do you stick into the equations to make them work?

One of the things I REALLY wish for is actually more control for the scenario designer of the environment. I mean... suppose you just assumed that omnidirectional noise level was a Gaussian distributed random number with some mean, m and some standard deviation, s. It'd be nice if the scenario designer could fill those values in. I'd have to really review Urick's chapter on the noise level. The real issue is not so much how to model it but more what options to include so that the system is as flexible as possible and still meaningful to people. Ya know? I come at it from the direction of a sonar geek, but someone else might say, "I don't want to stick in a mean and a standard deviation, I just want to say it's raining or there's a lot of shrimp snapping." That to me, though limits it's flexibility. To a certain extent, giving more control to the scenario designer also eliminates the need for data. It's essentially saying, "you can have any values you want anywhere, if you have some oceanographic database to justify it, all the better." There might be some default values for strategically interesting areas that we've researched, but even those should be changable.

Biological noise is complicated because it tends to be concentrated in specific areas but it shouldn't be constrained to them either. Off Cape Cod, for example, there's a very rich Marine preserve where there's tons of whales, dolphins and the entire ecosystem to support them. But it's also seasonal, so doing anything other than leaving it up to the user to include them means you need data. Do you know the distribution of whales globally as a function of time? What about shrimp? Seals? Croakers? Lobsters? Scallops? All fish with swim bladders? The list could be as long as you want.

The "bottom reflection" or reverberation issue is actually fairly complicated. Depending on sea state there's also surface reverberation. There's actually computer models built specifically for reverberation. I imagine that in order to get the desired effect you'd have to take into account grazing angle issues. You'd also have to worry about things like depression/elevation angle on the sonar set itself. Pointing the sonar beam pattern down might mean less reverberation, although less direct path range, pointing it up might increase reverberation but you also get more range. If you're planning to do stuff with just lookup tables, I'm not quite sure how to make this work. To make matters worse there's also volumetric scatterers in the water column that contribute to reverberation as well, so it's not just the bottom. You're also limited by the available data again.


Quote:

Originally Posted by Dr.Sid
Honestly I don't know much yet. I did not discuss this much with anyone.

By environment I mean background noise. This seems to be covered quite well in Urick, and there is no technical problem (I know of).

As for false targets .. there should be more bio targets, rocks, ice peaks or wrecks, all with both passive (water flow and eddies for silent ones) and active, and magnetic and so on when we get there.

Also for active the bottom reflection should be made better I think, especially if it's rocky, there should be a chance to hide at the bottom (I guess).

Any comments are appreciated.


Bubblehead Nuke 12-23-08 10:00 AM

Quote:

Originally Posted by SeaQueen
There are technical problems in terms of getting data. Even though theoretically we know how to model it to some reasonable approximation, the next question is, which numbers do you stick into the equations to make them work?

If we get 10% of your comments in the comsubsim, it will be better than what we have now.

Just as I, a nuke, will have to settle for approximations in ownship noise levels and the factors that control them, you as a sonar tech, will have to settle for a little less as well. Granted, I think that sensor data and the variables that create and modify them should be done to a greater extent. This is after all, a sensor sim.

Frame57 12-23-08 10:15 AM

Quote:

Originally Posted by Bubblehead Nuke
Quote:

Originally Posted by SeaQueen
There are technical problems in terms of getting data. Even though theoretically we know how to model it to some reasonable approximation, the next question is, which numbers do you stick into the equations to make them work?

If we get 10% of your comments in the comsubsim, it will be better than what we have now.

Just as I, a nuke, will have to settle for approximations in ownship noise levels and the factors that control them, you as a sonar tech, will have to settle for a little less as well. Granted, I think that sensor data and the variables that create and modify them should be done to a greater extent. This is after all, a sensor sim.

How true a statement, because if this were a "Subsim", where are the liberty ports and the girls...?:D

SeaQueen 12-23-08 06:42 PM

Quote:

Originally Posted by Bubblehead Nuke
Just as I, a nuke, will have to settle for approximations in ownship noise levels and the factors that control them, you as a sonar tech, will have to settle for a little less as well.

Actually, I'm not a sonar technician, I'm a physicist who happened to fall into the ASW business by accident. Don't short change me on nuclear stuff either. Something I think would actually be a fun addition to a nuclear subsim would be some reactor physics. Like... I know there's interesting transient states you can get the reactor in when you change throttle settings and you have to make a control rod adjustment. I sort wonder how to put that into a subsim such that there might be an "engineering panel" or something where you could manually adjust the throttle of the submarine.

SeaQueen 12-23-08 08:05 PM

Quote:

Originally Posted by Bubblehead Nuke
The devil is how to give someone an understanding of the engineering that goes into a sub without 'crossing' the line'.

As a general rule, my experience is that most of the engineering and science behind a given process is unclassified. I've never encountered anything purely engineering that was classified, except for things like how to manufacture radar absorbant materials and what not. The engineering of unique technologies that give the US a significant technological edge over the rest of the world are generally classified.

The laws of physics don't change across borders. It's no big secret how a nuclear reactor works, for example, or how beamforming works. You can find beautiful books on all of that. All of it is unclassified. Heck, we actually gave the technology to build nuclear reactors to Iran under that Atoms for Peace program in the 1950s under Eisenhower.

The problems pop up when people say, "here's how we do it specifically on this vessel, and oh, btw, here's some performance numbers."

Bubblehead Nuke 12-23-08 09:55 PM

Quote:

Originally Posted by SeaQueen
Quote:

Originally Posted by Bubblehead Nuke
The devil is how to give someone an understanding of the engineering that goes into a sub without 'crossing' the line'.

As a general rule, my experience is that most of the engineering and science behind a given process is unclassified. I've never encountered anything purely engineering that was classified, except for things like how to manufacture radar absorbant materials and what not. The engineering of unique technologies that give the US a significant technological edge over the rest of the world are generally classified.

The laws of physics don't change across borders. It's no big secret how a nuclear reactor works, for example, or how beamforming works. You can find beautiful books on all of that. All of it is unclassified. Heck, we actually gave the technology to build nuclear reactors to Iran under that Atoms for Peace program in the 1950s under Eisenhower.

The problems pop up when people say, "here's how we do it specifically on this vessel, and oh, btw, here's some performance numbers."

Oh, the physics is the easy part and no problem to get across or explain.

The actual details of power plant operation is not really a issue as it is far beyond the scope of any sim. Things like plant management and power constraints DO play a part as you can opt for low power/lower noise levels/lower max speeds vs high power/higher plant noise/higher max speed. Because of the nature of speed/drag/power curves there is no simple linear solution. You are able to make a trade-off that have a tangible tactical effect.

Since this IS a sim, these are things that need to be taken into consideration as they are a part of the operational equation. Unfortunatly, there is very little outside references into the operational considerations and tactical employement of a submarines. This is where those of us who have served try and give an insight without busting the rules.

Rip 12-24-08 04:35 PM

Quote:

Originally Posted by Frame57
Quote:

Originally Posted by Bubblehead Nuke
Quote:

Originally Posted by SeaQueen
There are technical problems in terms of getting data. Even though theoretically we know how to model it to some reasonable approximation, the next question is, which numbers do you stick into the equations to make them work?

If we get 10% of your comments in the comsubsim, it will be better than what we have now.

Just as I, a nuke, will have to settle for approximations in ownship noise levels and the factors that control them, you as a sonar tech, will have to settle for a little less as well. Granted, I think that sensor data and the variables that create and modify them should be done to a greater extent. This is after all, a sensor sim.

How true a statement, because if this were a "Subsim", where are the liberty ports and the girls...?:D

and field days?

:cry:


All times are GMT -5. The time now is 06:49 PM.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
Copyright © 1995- 2025 Subsim®
"Subsim" is a registered trademark, all rights reserved.