[0.24.x] Ideal SCANsat Altitudes v1.0 [Aug 16]

[technogeeky]

As an example of the new output, see this link.

I actually don't trust the error values that much; but as you can see, we now have too MUCH space.

[diomedea]

Yes, the format for the new tables is neat, effective. Much more user-friendly, values are quite understandable now .

BTW, as a previous user of ISA MapSat, as such with some knowledge of what the original algorithm by Psawhn was for, what you reported earlier makes sense. Thanks for sharing your thoughts, instead of just giving the conclusions. Some of the values you have removed were meaningless to me as well, though probably all were tabled to check how the algorithm worked (therefore, not all useful for final users).

[Drew Kerman]

looks great!

[DMagic]

Because SCANsat works differently than Mapsat, the resolution fields are incorrect and may not even be necessary. From what I understand, RAR uses 1x1 degree cells, Multi is locked to the resolution of the internal biome map, and SAR is arbitrarily high, correct? Or, you can get rid of the resolution value in degrees, and just fix the resolution value in metres.

Those values are used by the big map for display, but the internal scanning mechanism registers everything by lat/long integer values. So all scanners register to a 360 * 180 map when recording coverage. The big map just checks to see if a given lat/long is scanned, then fills in the data for that pixel (with the pixel location translated into a double precision lat/long values) accordingly based the scanner type.

[technogeeky]

OK. As one might see, I have now produced all of the tables for all of the planets. These occupy the 1st, 2nd, 3rd, 4th, and a few other posts on the front page (it all fits on the front page!).

All tables and albums are up-to-date, with the 5 scanner types supported.

[technogeeky]

Word. No worries on the response delay I figured you were busy

Thanks for the Rep. I apologize for the delay. It's one of those things where you know you are distributing bad information, and you want to stop that before you make even one more table.

Please let me know how your scanning journey goes.

[robot256]

Hey guys, sorry to bump the old thread, but wanted to say great work to technogeeky and Pshawn! Sorry I dropped out of the discussion last year after posting my update to Pshawn's script in the original ISA Mapsat orbit thread. I didn't realize you were revising it for Scansat this summer, and tried doing it myself without success (I somehow got it to produce nothing but resonant orbits o.0).

technogeeky, I don't know how far you got with the field-of-view/swath width recalculation, but I do work in remote sensing and it would indeed be really neat if they were more realistic. In reality, the swath width would be calculated trigonometrically like mohran's diagram (I used a version of that geometry in my version of the script). You talked about removing the "ideal altitude" and the penalty for being higher than it--I think there is actually a reason that going higher isn't necessarily better, but it can definitely have a better mathematical basis.

The main limiting factor of the swath width, after FOV, is the beam incident angle. In reality, you can't measure the altitude near the horizons because your radar pulse would be hitting the side of the mountain, not the top of it. Limiting the beam incident angle to something 10 or 30 degrees would make it so you have to be roughly above your scanning area to get a decent return, and being higher would give you slightly better incident angles but with diminishing returns. But actually, the maximum incident angle is more dependent on altitude, because at steeper angles the reflected signal is a lot weaker, so you would have to get closer to the planet to be able to pick it up. I don't have an immediate idea how to combine these factors into a balanced approach, so maybe what you're already doing makes the most sense anyways.

Please PM me if you want to talk about the math, or move this post somewhere else. I'm having a lot of fun with Scansat and can't wait to try out the orbit tables you posted here already!

[futrtrubl]

I think there is something I am not getting about these charts or maybe this is made for scansat v6 and something changed in v7 which I am using but...

I tried using the following from the Kerbin ORS table

              Altitude                Inc.       Orbital   Time to Scan          Eff.
  UEQx Sidelap  Ideal     +/- Error               Period      Total    +/- Error  FOV
=======================================================================================
    80 (1.01)  683.229 km +/- 0.94 km (77.00°)   1h 21.0m    53h 58.3m +/- 03.6m (4.0°)

with the karbonite scanner, KA_DetectionArray_01 which via MM has

MODULE
{
    name = SCANsat
    sensorType = 376960
    fov = 4
    min_alt = 5000
    max_alt = 750000
    best_alt = 100000
    scanName = Resource Scan
    power = 0.5
} 

Which seems to agree with your table with regards to FoV and altitude limits.

However when I put my satelite into the appropriate orbit (alt: 683.229, inc:77°) it doesn't cover the poles, the max latitude is about 81° which agrees with inc+FoV.

Edward

[sober667]

i have 1 question what is the height of scaning kerbol?( becouse i think it IS posible)

[Einarr]

I think there is something I am not getting about these charts or maybe this is made for scansat v6 and something changed in v7 which I am using but...

I tried using the following from the Kerbin ORS table

              Altitude                Inc.       Orbital   Time to Scan          Eff.
  UEQx Sidelap  Ideal     +/- Error               Period      Total    +/- Error  FOV
=======================================================================================
    80 (1.01)  683.229 km +/- 0.94 km (77.00°)   1h 21.0m    53h 58.3m +/- 03.6m (4.0°)

with the karbonite scanner, KA_DetectionArray_01 which via MM has

MODULE
{
    name = SCANsat
    sensorType = 376960
    fov = 4
    min_alt = 5000
    max_alt = 750000
    best_alt = 100000
    scanName = Resource Scan
    power = 0.5
} 

Which seems to agree with your table with regards to FoV and altitude limits.

However when I put my satelite into the appropriate orbit (alt: 683.229, inc:77°) it doesn't cover the poles, the max latitude is about 81° which agrees with inc+FoV.

Edward

This is normal, and you see it with several other scanners. I just use the orbit to get as much as I can, then alter my Inc to cover the poles. It only adds another 3-6 orbits at most, plus the fuel cost of the plane change. I was about to ask which Scanner type to reference for using the Karbonite scanner...

Edit: @technogeeky: You should consider updating the readme.md and associated text shown on this project's GitHub page as it does not contain the names of the ORS and EPL scanners in the scanner list provided. Granted, all I had to do was check the scanners.txt, but it's still good practice to keep such things updated.

i have 1 question what is the height of scaning kerbol?( becouse i think it IS posible)

No scanner has the range required to scan Kerbol. This wiki article tells us that any craft approaching within ~1 340 km of the surface of Kerbol will overheat and be destroyed, regardless of any cheats.

Edited November 19, 2014 by Einarr

[DBT85]

Has something changed or am I just a bit dense?

I've been testing these out as part of my SCANSat contract pack and have just gotten around to the Minmus Multispectral one. The very top orbit in this thread for Minmus and Multispec is

7 (1.22) 273.963 km +/- 1.24 km (44.41°) 7h 59.6m 27h 58.6m +/- 09.4m (12.6°)

I just put a craft in a 275km 44.3 degree orbit and it took at least twice the 27 stated hours to even get to 50%, because the top and bottom chunks of the map are being missed and apparently the tiny bit extra was making me be nearly resonant which wasn't helping. But I'll never get 100% if the top and bottom are never getting scanned at all.

All the others I've used thus far for Kerbin, Mun, Minmus, Eve, Duna and Ike have been fine. Am I being thick?

[diomedea]

Has something changed or am I just a bit dense?

I've been testing these out as part of my SCANSat contract pack and have just gotten around to the Minmus Multispectral one. The very top orbit in this thread for Minmus and Multispec is

7 (1.22) 273.963 km +/- 1.24 km (44.41°) 7h 59.6m 27h 58.6m +/- 09.4m (12.6°)

I just put a craft in a 275km 44.3 degree orbit and it took at least twice the 27 stated hours to even get to 50%, because the top and bottom chunks of the map are being missed and apparently the tiny bit extra was making me be nearly resonant which wasn't helping. But I'll never get 100% if the top and bottom are never getting scanned at all.

All the others I've used thus far for Kerbin, Mun, Minmus, Eve, Duna and Ike have been fine. Am I being thick?

I'd say nothing has changed, and not just because of SCANsat, but because the ideal orbits are tied mostly to each body rotation speed and gravitational parameter, only to a lesser degree to the scanning instruments used (FoV and max/min range); and while I know of no changes about the latter, sure there was none about the bodies in the Kerbol system. But sure you aren't thick, your question is a worthy one and I'm going to address it for what I know.

I use Scanning add-ons quite a lot, and the ideal/resonant orbits are a useful tool (so much that I compute ideal orbits parameters myself on a spreadsheet). Still, one of the best tools of all is the display on SCANsat big map of future orbital crossing markers, the pattern changes with the orbital period and if all markers group in a few locations, show at a glance the orbit resonancy. By looking at how those markers move, I can slightly change my orbit so to have them spread all over the globe. That, even while starting with one of the tabled altitudes (such as your example of Minmus top orbit).

But with that first orbit, the total scanning time (stated = 27h 58.6m) and orbital period (stated = 7h 59.6m) show it takes exactly 4 complete orbits to scan the whole globe (that means 8 equatorial crossings, but the first and last are at the same longitude being resonant, so 7 unique crossings). But, the multispectral tool has a FoV of 12.6° at that altitude, 7 crossings cover 7*12.6=88.2°. To cover 360° in longitude with a 12.6° FoV, it requires 29 unique crossings (15 whole orbits). Of course that shows the need to tweak the orbit for a resonance in 15 orbits, not in 4 orbits - therefore the orbital period has to change (actually, the 6th orbit in the table is computed for 29 UEQ, unique equatorial crossings, with a period of 3h 38.1m; however FoV at that altitude is roughly half at 6.7° - with 29 crossings that will only cover 194.3°, better but still much less than required). Checking all the orbits tabled, the only one fully covering Minmus is the last (145 UEQ * 2.8° FoV = 406° in longitude). And at the same time, that is also the one with the highest inclination of all (81.67°) therefore covering well the polar areas.

About inclination: the orbits are tabled so that every crossing is done along one meridian (the path on the ground of the scanning craft will be purely along a north/south direction at the equator). That is achieved with the inclination, so a slower orbit along with a faster rotating body requires a lower inclination for that north/south pass. But the tabled values obtained that way are no wiser, a low inclination is not much useful while scanning. One could think the tabled orbits are ideal ones for scanning (given this thread title) but with fast rotating low gravity bodies (Minmus sure, Gilly in particular) some are less than acceptable.

All the above said, I had similar issues as yours scanning Minmus: started with a tabled orbit and found it was taking much longer than expected to complete the scan. Good thing is orbital maneuvers are not that expensive around Minmus, computed myself a better approach, changed altitude and raised orbital inclination to match. Still took longer than the tabled orbit, but my complete Minmus scan was achieved within a reasonable time.

[thegreatgonz]

All the above said, I had similar issues as yours scanning Minmus: started with a tabled orbit and found it was taking much longer than expected to complete the scan. Good thing is orbital maneuvers are not that expensive around Minmus, computed myself a better approach, changed altitude and raised orbital inclination to match. Still took longer than the tabled orbit, but my complete Minmus scan was achieved within a reasonable time.

I, too, am finding that Minmus orbit #7 is disastrously bad, in a way that the other orbits in the OP are not.

[blnk2007]

I'd say nothing has changed, and not just because of SCANsat, but because the ideal orbits are tied mostly to each body rotation speed and gravitational parameter, only to a lesser degree to the scanning instruments used (FoV and max/min range); and while I know of no changes about the latter, sure there was none about the bodies in the Kerbol system. But sure you aren't thick, your question is a worthy one and I'm going to address it for what I know.

I use Scanning add-ons quite a lot, and the ideal/resonant orbits are a useful tool (so much that I compute ideal orbits parameters myself on a spreadsheet). Still, one of the best tools of all is the display on SCANsat big map of future orbital crossing markers, the pattern changes with the orbital period and if all markers group in a few locations, show at a glance the orbit resonancy. By looking at how those markers move, I can slightly change my orbit so to have them spread all over the globe. That, even while starting with one of the tabled altitudes (such as your example of Minmus top orbit).

But with that first orbit, the total scanning time (stated = 27h 58.6m) and orbital period (stated = 7h 59.6m) show it takes exactly 4 complete orbits to scan the whole globe (that means 8 equatorial crossings, but the first and last are at the same longitude being resonant, so 7 unique crossings). But, the multispectral tool has a FoV of 12.6° at that altitude, 7 crossings cover 7*12.6=88.2°. To cover 360° in longitude with a 12.6° FoV, it requires 29 unique crossings (15 whole orbits). Of course that shows the need to tweak the orbit for a resonance in 15 orbits, not in 4 orbits - therefore the orbital period has to change (actually, the 6th orbit in the table is computed for 29 UEQ, unique equatorial crossings, with a period of 3h 38.1m; however FoV at that altitude is roughly half at 6.7° - with 29 crossings that will only cover 194.3°, better but still much less than required). Checking all the orbits tabled, the only one fully covering Minmus is the last (145 UEQ * 2.8° FoV = 406° in longitude). And at the same time, that is also the one with the highest inclination of all (81.67°) therefore covering well the polar areas.

About inclination: the orbits are tabled so that every crossing is done along one meridian (the path on the ground of the scanning craft will be purely along a north/south direction at the equator). That is achieved with the inclination, so a slower orbit along with a faster rotating body requires a lower inclination for that north/south pass. But the tabled values obtained that way are no wiser, a low inclination is not much useful while scanning. One could think the tabled orbits are ideal ones for scanning (given this thread title) but with fast rotating low gravity bodies (Minmus sure, Gilly in particular) some are less than acceptable.

All the above said, I had similar issues as yours scanning Minmus: started with a tabled orbit and found it was taking much longer than expected to complete the scan. Good thing is orbital maneuvers are not that expensive around Minmus, computed myself a better approach, changed altitude and raised orbital inclination to match. Still took longer than the tabled orbit, but my complete Minmus scan was achieved within a reasonable time.

Could you dropbox your spreadsheet?

[Spheniscine]

Kerbin values need updating, now that its rotation speed has been adjusted so that 6 hours is its solar day, not its sidereal day.

[frango9000]

Ill leave this here in case any1 wants the old post 

http://webcache.googleusercontent.com/search?q=cache:tbvBM29Y7d8J:forum.kerbalspaceprogram.com/threads/75854-0-24-x-Ideal-SCANsat-Altitudes-v1-0-Aug-16

[meyerweb]

On 12/1/2015 at 7:45 PM, frango9000 said:

Ill leave this here in case any1 wants the old post 

http://webcache.googleusercontent.com/search?q=cache:tbvBM29Y7d8J:forum.kerbalspaceprogram.com/threads/75854-0-24-x-Ideal-SCANsat-Altitudes-v1-0-Aug-16

That link didn’t work for me, so I went cache fishing.  I cleaned up what I could find and threw the result up on my personal site as static HTML: http://meyerweb.com/eric/ksp/024-ideal-scansat-altitudes-v10.html

If those orbits are out of date or otherwise bad, let me know and I’ll slap a warning at the top of the page.

[Neutrinovore]

On ‎8‎/‎16‎/‎2014 at 1:13 AM, technogeeky said:

OK. As one might see, I have now produced all of the tables for all of the planets. These occupy the 1st, 2nd, 3rd, 4th, and a few other posts on the front page (it all fits on the front page!).

All tables and albums are up-to-date, with the 5 scanner types supported.

I realize that Technogeeky doesn't seem to be active here on the forums much anymore, but I just thought I'd check in to mention that I don't find any information about the Kerbin system (Kerbin, Mun, & Minmus) anywhere in this thread, updated or otherwise.  There's everything else, just nothing about the Kerbin system.  In scanning the thread quickly, I've picked up a few comments alluding to the fact that some things may have changed in 1.0.5, or perhaps even before, that could have an effect on some of these charts, so if that's the case, I suppose I can just resort to 'trial and error' in fixing my problem.  Oh, I guess I should mention what that is, yes?    Using old data from over a year ago, actually it's the same charts that are linked in the post directly above by Meyerweb (thanks, btw, it is good to have a way to get to those older posts!), I was scanning Minmus, and all of the orbits I'm using (SCANSat: RADAR, SAR, and Multispectral) are resonant, instead of non-resonant, resulting in a criss-cross pattern of scan results, with blank areas in between.  I'm going to try another set of parameters to see if it just so happens that the ones I chose were the only 'bad' ones in there, but... well, we'll see.

Anyway, I hope this thread hasn't been totally abandoned, it's a really useful tool to have for those of us who use the various surface scanning mods that have been developed for this great game!

Later all! 

 

 

Edited January 1, 2016 by Neutrinovore

[meyerweb]

On 1/1/2016 at 3:10 AM, Neutrinovore said:

Using old data from over a year ago, actually it's the same charts that are linked in the post directly above by Meyerweb (thanks, btw, it is good to have a way to get to those older posts!), I was scanning Minmus, and all of the orbits I'm using (SCANSat: RADAR, SAR, and Multispectral) are resonant, instead of non-resonant, resulting in a criss-cross pattern of scan results, with blank areas in between.

I’ve also noticed that some of the orbits have at least some parameters completely wrong.  Example: the farthest-out Minmus SAR orbits, from UEQx 5 through 21, show an inclination of 0.00º.  Having just tried one of them (~730Km @ 0.00º), I can assure you that these will not suffice unless your goal is to image only the equator.  I switched the orbit to 89.5º—trivial to do at that distance, since orbital speed is less than 50m/s—and will see what I get, but it seems that some of the data I was able to rescue is wrong.  Whether it started life wrong, or was mangled by caching and rescuing, I do not know at this point.

[Mall0xZEN]

On 15.08.2014 at 8:16 AM, technogeeky said:

As an example of the new output, see this link.

I actually don't trust the error values that much; but as you can see, we now have too MUCH space.

Is this method still working?

[JoE Smash]

1. I can't find Minmus in the OP list at all....

2. I don't even understand how to read any of the data here...

Are all the initial values followed by "km" all ideal orbital altitudes?

I though the ideal altitudes were 750km for the SAR and 250km for pretty much everything else.

Lastly I put my SAR at around 750km above Minmus and it still says "sub-optimal" for orbit AND it's moving SOOOOOOO slow. I also seem to be at like 9% for days.

Can someone please tell me the ideal orbital altitudes for Minmus?

[Jellybug]

Hi, all - just returned to the game after a long hiatus. If anyone is interested in running this program with the new scanners and updated planet data, I've made changes to the two definition files.

I can get results from these, but I'm not sure if SCANsat is working the same way (specifically, interpolating FOV as altitude changes) as it was when Technogeeky programmed this, so I'm not sure how well the recommended orbits will work.

scanners.txt

Name	FOV	HalfFOV	AltitudeMin	AltitudeIdeal	AltitudeMax	LongName
AltLo1	1.50	0.75	05000.00	70000.00	250000.00	R-3B Radar Altimeter
AltLo2	3.50	1.75	50000.00	100000.00	500000.00	R-EO-1 Radar Antenna
AltHi1	1.50	0.75	70000.00	250000.00	500000.00	SAR-X Antenna
AltHi2	3.00	1.50	500000.00	700000.00	750000.00	SAR-C Antenna
AltHi3	4.00	2.00	250000.00	500000.00	1000000.00	SAR-L Antenna
ResLo0	3.00	1.50	15000.00	500000.00	7500000.00	M700 Survey Scanner
ResHi0	2.00	1.00	10000.00	150000.00	500000.00	M4435 Narrow-Band Scanner
ResHi1	1.00	0.50	20000.00	70000.00	250000.00	SCAN-R Resource Mapper
ResHi2	2.50	1.25	70000.00	250000.00	500000.00	SCAN-R2 Advanced Resource Mapper
ResHi3	3.00	1.50	100000.00	500000.00	750000.00	SCAN-RX Hyperspectral Resource Mapper
Multi1	3.00	1.50	20000.00	70000.00	250000.00	MS-1 Multispectral Sensor
Multi2	1.50	0.75	70000.00	300000.00	400000.00	MS-R Enhanced Multispectral Sensor
Multi3	4.00	2.00	100000.00	500000.00	750000.00	MS-2A Advanced Multispectral Sensor
VisHi1	1.50	0.75	20000.00	70000.00	250000.00	VS-1 High Resolution Imager
VisHi2	2.50	1.25	70000.00	350000.00	500000.00	VS-3 Advanced High Resolution Imager
VisHi3	4.00	2.00	100000.00	200000.00	1000000.00	VS-11 Classified Reconnaissance Imager

planetInfos.txt

Name	Radius		Day		GM			SOI		Atmo
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Kerbol	26160000.00	432000.000	1172332800000000000.000	999999999999.00	0.000
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Moho	250000.00	1210000.000	168609378654.509	9646663.000	0.000
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Eve	700000.00	80500.000	8171730229210.87	85109365.000	90000.000
Gilly	13000.00	28255.000	8289449.81471		126123.270	0.000
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Kerbin	600000.00	21549.425	3531600000000.000	84159286.000	70000.000
Mun	200000.00	138984.380	65138397520.7807	2429559.100	0.000
Minmus	60000.00	40400.000	1765800026.31247	2247428.400	0.000
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Duna	320000.00	65517.859	301363211975.098	47921949.000	50000.000
Ike	130000.00	65517.862	18568368573.144		1049598.900	0.000
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Dres	138000.00	34800.000	21484488600.000		32832840.000	0.000
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Jool	6000000.00	36000.00	282528004209995.000	2455985185.000	200000.00
Laythe	500000.00	52980.879	1962000029236.08	3723645.800	50000.000
Vall	300000.00	105962.090	207481499473.751	2406401.400	0.000
Tylo	600000.00	211926.360	2825280042099.95	10856518.000	0.000
Bop	65000.00	544507.430	2486834944.41491	1221061.900	0.000
Pol	44000.00	901902.620	721702080.000		1042138.900	0.000
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Eeloo	210000.00	19460.000	74410814527.0496	119082942.000	0.000

 

[Arrowmaster]

I have added the above changes to a github fork and the results seemed to be accurate for me when I used them last year. I have stopped playing stock and switched over to RSS/RP-1 so I hope to get the scanners from RP-1 and additional RSS planet values added and test the accuracy. Unfortunately I do not know MATLAB or understand the math behind any of this so if the calculations are off, I have no way of correcting them.

https://github.com/arrowmaster/MapSatAltitude