In January 2026, ISRO’s Space Applications Centre published a two-page abstract at the 57th Lunar and Planetary Science Conference describing five candidate landing sites on Mons Mouton for the Chandrayaan-4 mission (Amitabh et al., LPSC 2026, #1198).

Based on engineering constraints, MM-4 was identified as the primary landing location for Chandrayaan-4. The site was evaluated for slope safety, boulder hazards, and sunlight availability, and a 1 km × 1 km area within it was found to have

the least hazardous terrain. The final landing site was selected using the following criteria:

• Slope <= 10°

• Boulders < 0.32 m diameter (detection limit because of OHRC pixel resolution for the acqusitions)

• Crater and boulder distribution

• Sunlit for at least 11–12 days per lunar cycle

• Local terrain features don’t shadow the site for prolonged durations

• Distribution of safe 24 m × 24 m grids inside the 1 km × 1 km landing area

While these appear to be the standard criteria for ISRO’s landing site evaluations, the approach for Chandrayaan-3 — which landed much further north at 69.37°S, 32.35°E (between Manzinus U and Boguslawsky M craters) — was notably more elaborate. For CH3, ISRO evaluated a much larger 4 km × 2.4 km landing zone and applied a multi-grid assessment at three scales: 24 m × 24 m, 36 m × 36 m, and 48 m × 48 m (Amitabh et al., LPSC 2023, #1037). The winning site (LS-2) had 3,901 safe 24 m grids across the full zone.

The reason for this multi-scale approach was operational, not just analytical. CH3’s Vikram lander carried an onboard Hazard Detection and Avoidance (HDA) system (Suresh & Amitabh, LPSC 2024, #2250) that worked in two modes. In 3D mode, a camera image captured during hovering at ~150 m altitude was matched against a pre-stored OHRC orthoimage to localize the lander’s position within the 4 km × 2.4 km zone.

Once localized, the lander extracted the corresponding region from a pre-uploaded binary hazard map — prepared at 4 m grid spacing from the OHRC DEM — and searched for the nearest safe 24 m × 24 m grid to divert to if its nadir point was unsafe.

In 2D mode (a salvage option), the lander computed a hazard map in real-time from the descent camera image alone. The hazard map marked grids as unsafe based on four criteria: craters > 1.2 m, boulders > 0.32 m, slope > 10°, and shadow at the time of landing.

Additional mission constraints — Earth-Moon radio communication visibility and continuous illumination for 14 days — were also factored in. The multi-grid evaluation at 48 m, 36 m, and 24 m scales ensured that safe zones existed at multiple footprint sizes, giving the HDA system viable divert options regardless of where the lander ended up within its descent corridor. The landing area had been expanded from the original CH2-era 500 m × 500 m to 4 km × 2.4 km specifically to accommodate along-track and across-track trajectory dispersions during terminal descent.

For CH4, the landing box has shrunk to 1 km × 1 km with only the 24 m grid presumably tighter descent dispersions from improved navigation confidence gained during CH3’s successful landing.

I have the same Level-1 OHRC stereo imagery from ISRO’s PRADAN archive. The question: can I independently reproduce their analysis, and what can I learn about the methodology along the way?

The short answer: the DEM checks out, the alignment to LOLA reveals a 4.8 km offset that is entirely expected (which I realised later), and reverse-engineering the hazard classification turns out to be more interesting than I anticipated. In this post, I cover the DEM generation, LOLA alignment, and the first criterion — slope analysis. The full multi-criteria hazard map is a work in progress.

The Data

A note on the paper: the acquisition date is listed as November 2025, but the orbit numbers (23353/23354) correspond to November 2024 products in ISRO’s archive — a one-year typo.

The Figure-1 coordinate table also appears to have a site numbering swap (MM-3 and MM-4 coordinates are interchanged). They matter if you’re trying to reproduce the work programmatically, but they don’t undermine the science.

The stereo pair for MM-4 was acquired on consecutive orbits with opposite spacecraft pitch angles — +17.28° (forward-looking) and −17.13° (aft-looking) — producing a 36.89° convergence angle across a 63.7 km baseline. Both images were captured from ~95 km altitude at ~0.24 m/px ground sample distance, covering nearly identical swaths of 12,000 × ~101,000 pixels each. Solar incidence angles of 84–86° mean the sun was only 4–6° above the horizon, casting long shadows that enhance visual boulder detection but degrade stereo correlation in shadowed terrain.

The images come from Chandrayaan-2’s OHRC — the same camera I used for my previous DEM at the Chandrayaan-3 landing site. Quick specs:

• Detector: 12,000-pixel TDI line array, 5.2 µm pitch

• Focal length: 2080 mm

• GSD: ~0.24 m/px (varies slightly with altitude)

• Spectral band: 450–800 nm panchromatic

The catch: solar incidence is 84–86°. The sun is barely 4–5° above the horizon. Every surface feature throws a long, dramatic shadow — great for spotting boulders visually, terrible for stereo matching where those shadows leave no texture to correlate.

Building the High Resolution Elevation Map

I’ve covered the full pipeline in my previous post, so I’ll focus on the key numbers here.

The pipeline is the same: ISIS for ingestion and SPICE initialization, CSM camera models via a custom ISD generator, ASP for bundle adjustment, stereo correlation, and DEM generation.

Bundle adjustment was the most time-consuming step at ~9 hours, dominated by interest point matching on the full uncropped 12,000 × 101,000 pixel strips. 578k interest points were detected per image, filtered down to ~115k matches after outlier removal, with 10,000 used for the actual optimization. The solver converged in 21 iterations, reducing cost by 97.8% (14,203 → 308) with a final mean reprojection error of 0.31 pixels.

Stereo correlation used ASP’s MGM (More Global Matching) algorithm via parallel_stereo. The first pass with a 1-hour correlation timeout completed 275 of 296 tiles. A second pass at 2 hours recovered 12 more, leaving 9 tiles failed — all in deep shadow zones at strip edges where 84–86° solar incidence leaves no texture to correlate. ISRO’s in-house software handles these regions; ASP’s MGM doesn’t. The gaps are at the margins, not in the landing site area.

DEM generation with point2dem produced a 26,366 × 77,340 pixel grid at 0.289 m/px (auto-computed by ASP), spanning ~7.6 × 22.3 km with an elevation range of 4,729–5,618 m. Valid pixel coverage is 32.4% of the full grid — low because most of the grid falls outside the stereo overlap, but the overlap region itself has near-complete coverage.

The 10.8 cm median triangulation error is excellent — well below a single pixel of GSD. For a 29 cm DEM built from ~95 km altitude with challenging 85° solar incidence, that’s right where it should be.

I also spent an unreasonable number of iterations matching ISRO’s color DEM palette — a non-standard ramp from teal through brown and red to pink-white, with unevenly spaced transitions — a Vanity project, but satisfying.

The Result: a 29cm elevation map

The orthoimage is the left stereo image reprojected onto the DEM surface — a map-projected view as if looking straight down, with terrain distortion removed. The grayscale DEM encodes elevation as brightness (white = high, dark = low), covering only the stereo overlap region where both images had matching texture. The colour DEM applies a palette across the 4,830–5,700 m elevation range to make topographic features visually distinct — the large dark crater near the top of the strip and the broad plateau of Mons Mouton are immediately apparent.

The black gaps in the DEM are shadow voids — regions where stereo correlation failed entirely. At 84–86° solar incidence, the sun is barely 4–6° above the horizon. Crater walls, ridges, and even modest undulations cast shadows that can stretch 10× the feature height. In these shadowed pixels, both stereo images record near-zero DN values with no texture for the correlator to match, producing no disparity and no 3D points.

These gaps are concentrated at strip edges and inside deep craters — not in the MM-4 landing site area. Of 296 stereo tiles, 9 failed even with a 2-hour correlation timeout, all in shadow-dominated regions.

Interestingly, ISRO’s published DEM and colour relief products show no such gaps — the coverage appears seamless even through shadowed terrain. The most likely explanation is algorithmic: ISRO’s OPTIMUS which almost certainly includes shadow-aware interpolation or multi-pass gap-filling as part of the production pipeline. ASP’s MGM correlator, by contrast, is conservative — if it can’t find a confident match, it reports no data rather than guessing.

ISRO may also leverage the slight difference in solar geometry between the two acquisitions (~1.5° change in solar incidence over the ~2 hour gap between orbits), using the image with marginally better shadow illumination to fill regions that are fully dark in the other. A third possibility is that ISRO applies shape-from-shading (photoclinometry) within shadow zones, using the faint secondary illumination from earthshine or terrain-scattered light to recover surface shape where stereo fails. Whatever the method, the gap-free result is a production pipeline advantage — though it’s worth noting that interpolated or photoclinometry-derived elevations in shadow zones carry higher uncertainty than stereo-derived values in well-lit terrain.

At this stage, the strip’s absolute position on the Moon is offset by ~4.8 km from its true location due to SPICE ephemeris errors. The internal geometry is accurate (10.8 cm triangulation error), but the whole strip needs to be shifted into place — which is what LOLA alignment does in the next section.

LOLA Alignment: The 4.8 km Surprise

Why align — Solving the coordinate misunderstanding

ISRO’s published MM-4 coordinate (-84.289°, 32.808°) fell in a nodata gap in my original (pre-alignment) DEM. After the 4.8 km northward shift: 100% valid coverage at that location. The coordinate was always correct — my DEM was just offset.

This also resolved the “coordinate mystery” from my first draft. The ~4 km discrepancy between the published coordinate and where I’d found the best statistical match? That was the alignment offset. Once the DEM is in the right place, the published coordinate lands exactly where it should.

SPICE camera models — the spacecraft position and pointing data used to build the sensor model — carry systematic errors. The DEM is geometrically correct internally (triangulation error: 10.8 cm), but its absolute position on the Moon will be offset, and this is expected. Every planetary data product built from orbital imagery has this problem until it is tied to a known independent reference. What “offset” really means here is that the coordinates in my DEM don’t agree with the coordinates in any other dataset — LOLA, LROC, even ISRO’s own published site locations. The terrain is right; the address is wrong. Alignment fixes the address.

Choosing the reference

The standard reference for absolute lunar positioning is LOLA — the Lunar Orbiter Laser Altimeter on LRO — which provides the definitive elevation reference for the Moon. In practice, most alignment work uses LOLA-derived gridded products known as “LDEMs” rather than raw altimetry tracks.

The product I used: LDEM_83S_10MPP_ADJ.TIF (Barker et al., 2023 Planet. Sci. J., 4, 183) a 10 m/px gridded DEM covering 83°S to the pole in south polar stereographic projection.

This matters because for my CH3 (Chandrayaan-3 landing site) alignment (arXiv:2602.14993) , I used hand-gridded LOLA RDR point shots — RDR being “Reduced Data Record,” the individual laser altimetry returns with latitude, longitude, and elevation for each pulse, as opposed to the gridded LDEM which interpolates millions of these returns into a continuous surface. The result was mediocre: 42 m median error. Switching to the official gridded LDEM product turned out to be 27× more accurate. The whole process of selecting references, running iterative alignment, and validating results gets tedious — in my previous post I’ve explained the methodology in detail. For now, the key is choosing a reference product that actually covers your regionof interest at sufficient resolution. This is where QuickMap comes in extremely handy — it lets you browse available data products and check coverage before committing to a reference.

Alignment

Step 1: Reproject both DEMs to the same CRS at 10 m. My DEM lives in an oblique stereographic projection; LOLA in south polar stereo. I reprojected mine into LOLA’s CRS at 10 m resolution.

Step 2: Translation-only ICP. First pass — just find the bulk shift, no rotation.

• Initial median error: 175 m

• Final median error: 15.7 m

• Translation: 4,806 m, almost entirely northward

A 4.8 km offset. That’s large but not surprising — SPICE ephemeris errors of several kilometres are typical for lunar orbiters without ground control points, as explained earlier.

Step 3: Rigid refinement. Point-to-plane ICP seeded with the translation, now allowing rotation.

• Initial: 13 m → Final: 1.54 m median

• Rotation: 0.18°

• Converged in 7 iterations

Step 4: Apply to full-resolution point cloud. The ICP was done at 10 m resolution for speed. Now apply the same rigid transform to the original ~0.3 m point cloud, then regenerate the DEM.

The rigid transform preserves internal geometry perfectly — triangulation error is identical before and after alignment.

The full alignment process is non-trivial and involves several careful decisions about reference selection, convergence criteria, and transform direction (I’ve documented the methodology in detail in my previous post). I’ve condensed it here to the numbers that matter — because for everything that follows, one number matters most: 1.54 m. That tells me the aligned DEM and orthoimage agree with the global LOLA reference to within 1.54 metres (!!) on average. That is an exceptionally good alignment — it means I can overlay my 29 cm products on any other lunar dataset and trust that features line up to within a couple of metres.

here you can see this clearly:

I’m refining this pipeline as I learn new things — each site I process teaches me something about reference selection, convergence behaviour, or edge cases. I’ve published my findings, methodology, results, and validations in a preprint:

Geodetically Anchored 0.30m Digital Elevation Model of the Chandrayaan-3 Vikram Landing Site from Chandrayaan-2 Orbital High Resolution Camera (OHRC) Stereo Imagery (Tungathurthi, 2025, preprint here )

and a formal journal submission is in preparation.

There’s no publicly available end-to-end guide for aligning CH2 OHRC products to LOLA, and it shouldn’t require the number of iterations it took me to get here.

The Potential Landing site

With the aligned DEM in hand, I can finally do what I set out to do: draw a 1 km × 1 km box at ISRO’s published coordinates (-84.289, 32.808)and examine the terrain.

ISRO’s LPSC abstract identifies MM-4 as the preferred site and provides a coordinate for the selected 1 km × 1 km landing area within it. This is the area within which the lander must touch down — significantly smaller than Chandrayaan-3’s 4 km × 2.4 km landing zone, reflecting tighter descent dispersions. After LOLA alignment, this coordinate falls squarely within high-quality DEM coverage — 100% valid pixels, no shadow gaps. The landing box sits on the relatively flat plateau of

Mons Mouton, flanked by small craters and gentle undulations, with an elevation range of about 100 metres across the full kilometre.

Box orientation matters

One subtlety I didn’t appreciate initially: the 1 km × 1 km box is defined with respect to ISRO’s south polar stereographic projection (centred at 90°S). My DEM uses oblique stereographic centred on the strip (lat₀ = −84.2°). A box that is axis-aligned in polar stereo is rotated ~33° relative to a box axis-aligned in my oblique stereo — because at longitude ~33°E, the polar stereo grid axes point in a different direction than the oblique stereo grid axes.

Both boxes are centred on the same latitude/longitude. But they cover different pixels due to the rotation, so the statistics differ slightly. When comparing with ISRO, you have to match their CRS.

Comparing with ISRO’s stats

The ~10 m elevation offset is the LOLA alignment residual — a 1.54 m median means some areas are a few metres higher, others lower, and the mean offset at this particular location happens to be around 10 m. The slope difference (5.0° vs 5.65°) is consistent with different DEM resolutions and processing algorithms: our finer 0.289 m grid resolves more micro-terrain than ISRO’s 0.32 m grid, which slightly inflates the mean slope.

Hazard Mapping: The First Criterion — Slope

The first and most fundamental criterion in ISRO’s hazard classification is slope: any terrain steeper than 10° is flagged as unsafe. This is a hard engineering constraint — the lander’s legs and descent guidance are designed to handle up to 10° of local tilt at touchdown.

The most telling comparison is the safe grid count: 1,703 vs 568. Our count is higher because we’re only applying the slope criterion. ISRO applies all six criteria — slope, boulders, craters, illumination, shadow duration, and grid distribution. Additional criteria can only remove grids, never add them. So 1,703 > 568 is exactly correct: slope is a permissive filter at this site, and the other criteria — particularly illumination — do most of the heavy lifting.

The remaining criteria — boulder detection, crater mapping, illumination modelling, shadow duration, and grid distribution — are where the analysis gets genuinely difficult. Illumination in particular requires ray-tracing over a full lunar year at a latitude where the sun never climbs above 7°, and no public product exists at sufficient resolution for this site. In the next post, I’ll tackle these remaining criteria and attempt to recreate the full multi-criteria hazard map to compare directly with ISRO’s published Figure 6.

The foundation is solid. The interesting work is ahead.

Putting It All Together: 3D Terrain Mapping

To get a sense of what the lander will actually face, here’s the aligned DEM draped with the orthoimage and rendered as a 3D terrain slab from six perspectives. The elevation colour ramp (green = low, red = high) is blended with the orthoimage at 45% opacity to preserve surface texture — craters, boulder shadows, and micro-terrain are all visible alongside the elevation gradient.

The 1 km × 1 km landing box spans an elevation range of ~103 m (Δ = 103 m). The terrain is broadly flat with a gentle northward slope, punctuated by small craters and subtle ridges. From the bird’s-eye view, the scale of the site relative to individual craters becomes clear — most hazardous features are well under 50 m across. From the low-angle views, you can appreciate why slope matters: even modest undulations become significant when viewed at the 4–6° sun angles this site experiences.

Conclusion

Starting from the same Level-1 OHRC stereo imagery available on ISRO’s PRADAN portal, I’ve independently produced a 29 cm DEM with 10.8 cm triangulation error, aligned it to the global LOLA reference to within 1.54 m, and validated the first of ISRO’s six hazard criteria against their published numbers. The elevation statistics agree to within the alignment residual. The slope analysis confirms that terrain steepness alone is a permissive filter at MM-4 — 97% of 24 m grids pass —meaning the other five criteria do the real work of narrowing 1,703 slope-safe grids down to ISRO’s 568.

The remaining criteria — boulder detection, crater mapping, illumination modelling, shadow duration, and grid distribution — are where the analysis gets genuinely difficult. Illumination in particular requires ray-tracing over a full lunar year at a latitude where the sun never climbs above 7°, and no public product exists at sufficient resolution for this site. In the next post, I’ll tackle these remaining criteria and attempt to recreate the full multi-criteria hazard map.

The data is public. The tools are open-source. The methodology is published. ISRO’s numbers are there to be checked against — anyone should be able to verify them independently. That’s the point.

All processing done with open-source tools: ISIS 9.0.0, ALE 0.11.0, ASP 3.6.0, GDAL, and Python. Raw data from ISRO’s PRADAN portal. Full pipeline methodology published in Tungathurthi (2025).

~FIN

This blog post provides technical documentation of the DEM generation workflow for reproducibility purposes only. A separate manuscript presenting the complete geodetic alignment methodology, quantitative validation, and statistical analysis is currently in preparation for journal submission.

preprint: arXiv:2602.14993

In my previous analysis of OHRC’s operational capabilities, I highlighted one of the instrument’s most compelling design goals: Ultra-High Resolution Stereo Imaging. By capturing multi-view stereo images within a single orbit through different spacecraft orientations, OHRC enables the creation of digital elevation models with equally high spatial resolution. ISRO’s Space Applications Centre (SAC) uses a purpose-built indigenous software called OPTIMUS to generate these DEMs internally, reportedly producing approximately 28 cm horizontal and 100 cm vertical resolution elevation data.

The DEM generation methodology was discussed in 52nd LPSC conference which includes the terrain characterization for Chandrayaan-3 landing site selection — work that clearly demonstrates the value of these elevation products, the OHRC-derived DEM unfortunately are not available to the public or to the broader scientific community. The imagery and the spacecraft’s position and attitude are released. But, the derived science products remain behind institutional walls.

Now, I want to be clear about something: I’m proud that India has a camera like this in lunar orbit. OHRC is, at the time of writing, the only operational orbital camera at the Moon capable of sub-25 cm imaging. NASA’s LROC Narrow Angle Camera (NAC) — the next best thing — achieves ~0.5 m/px optical resolution, and its best DEMs reach 2–5 m/px from stereo or ~1 m/px from photoclinometry at a handful of selected sites at the poles. NASA+KARI’s ShadowCam is optimized for permanently shadowed regions (PSR) at ~1.7 m. OHRC stands alone in its resolution class — and that is a genuine achievement by SAC and the teams that designed and built it. When I spotted the IM-2 Athena lander and, before that, Japan’s SLIM in OHRC imagery, it was a reminder of just how powerful this instrument is. As an Indian, there’s a real sense of pride in knowing that this capability exists, orbiting the Moon right now, capturing data that no other active mission can match.

Which is exactly why it’s frustrating that the derived products don’t get released — so I decided to build them myself.

Why Elevation Maps Matter More Than Pretty Images

Before getting into the technical journey, it’s worth understanding why a Digital Elevation Model (DEM) is fundamentally different from — and arguably more valuable than — the imagery itself.

An OHRC image tells you what the surface looks like. A DEM tells you what the surface actually is. It encodes the three-dimensional shape of the terrain: every slope, every depression, every boulder. From a DEM you can compute slope maps, identify safe landing zones, measure crater depths, estimate regolith properties from degradation patterns, and plan traverse routes for rovers. None of that is possible from a flat image alone.

This is exactly why DEM generation was identified as a key capability in the original OHRC instrument paper by Chowdhury et al. (2020).

A software pipeline has been developed to process OHRC DSS images (~3 km × 12 km), which is capable of generating DEM in 21 min after receiving the second orbit data. Regular operations products are according to defined levels. There are three levels (0, 1 and 2) defined for OHRC data products.

(…)

Level-2 datasets include both radiometric and geometric correction. DEM generation and Ortho correction using Lunar control points or reference data are planned for stereo acquisitions.

It isn’t an afterthought. It is one of the primary justifications for the instrument’s design — the narrow field of view, the high-resolution TDI detector, the stereo maneuvering capability. The instrument was built for this. The paper itself describes the stereo DEM capability as a core deliverable.

And yet, over five years after Chandrayaan-2 reached lunar orbit, the best publicly available elevation data for the Moon comes from NASA’s Lunar Reconnaissance Orbiter. LOLA provides global coverage at roughly 30 meters per pixel, with select high-density passes achieving about 1 meter. The gap between what OHRC can theoretically produce and what anyone outside ISRO can actually access is nearly two orders of magnitude.

The Open-Source Ecosystem That Made This Possible

I’ll be honest: I spent months on this. Not months of continuous processing — months of reading documentation, figuring out data formats, hitting dead ends, trying things that didn’t work, and slowly piecing together a workflow that does. And none of it would have been remotely possible without open-source tools built and maintained by people who chose to make their work available to everyone.

ISIS (Integrated Software for Imagers and Spectrometers), developed by the USGS Astrogeology Science Center, is the backbone of planetary image processing. It handles raw data ingestion, SPICE kernel management, and camera model computation. It has been open-source, supporting missions from Voyager to Mars Reconnaissance Orbiter to, now, Chandrayaan-2.

The Ames Stereo Pipeline (ASP), developed by NASA’s Intelligent Robotics Group at Ames Research Center, does the heavy lifting of stereo photogrammetry: feature matching, bundle adjustment, triangulation, and DEM generation. Open-source, actively maintained, and well-documented.

ALE (Abstraction Library for Ephemerides), also from USGS, provides the camera model abstraction that connects mission-specific sensor geometry to the Community Sensor Model (CSM) framework — which turned out to be the key that made OHRC processing practical.

Granted this can be overwhelming at the beginning, especially if you have no prior experience with these tools. And the support for Chandrayaan-2 data specifically OHRC and TMC2 only started to be available recently and it hasn’t been officially released yet, as the the development is being actively worked on.

The Chandrayaan-2 OHRC driver in ALE is still not finished yet but it does work, the PDS4 import template in ISIS, the ASP documentation page for Chandrayaan-2 — all of that exists. I genuinely appreciate that effort, and I think it deserves more recognition than it gets.

ISRO’s approach has been different. Their processing software is proprietary and rather fully in-house and, their derived products stay internal, and their data access policies can be inconsistent. I’ve written before about the level of opacity ISRO maintains regarding operational specifics. I understand there are institutional reasons for this — priorities, resources, policy — and I don’t think it comes from a place of bad intent. But from the perspective of someone trying to do science with Indian mission data, there is a real gap.

This is ultimately why open-source matters. When the institution doesn’t release the product, the tools let you build it yourself.

The Data: What You Get and What You Have to Hunt Down

OHRC stereo pairs are created by maneuvering the Chandrayaan-2 spacecraft on consecutive orbits — tilting roughly 5° on one pass and about 25° on the next — so the same terrain gets imaged from two different viewing angles. This creates the convergence geometry needed for 3D reconstruction.

The ingredients for DEM generation are:

1. Stereo image pairs in PDS4 format, released through ISRO’s PRADAN portal

2. SPICE kernels — attitude files and orbital position files, released separately on PRADAN

3. Calibration lookup tables — gain and bias per pixel, specific to the detector mode used during capture

Finding the right stereo pairs was its own challenge. I’ve been building a lunar data portal called Soma — something like ISRO’s CH-2 Browse or NASA’s QuickMap — that lets me search the OHRC catalogue by location, date, resolution, and solar geometry.

I haven’t released it yet, but I plan to make it available to the wider community soon. It proved essential here: without a way to quickly identify which image strips actually overlap and form viable stereo pairs, I’d still be scrolling through metadata tables.

For this first release, I targeted the Shiv Shakti Point region — the area around Chandrayaan-3’s Vikram landing site.

In total, I ended up downloading the entire catalogue of OHRC positional data and imagery. Over 120 GiB of data. My internet connection was not happy about it.

The Processing Pipeline: Step by Step

Here is the complete pipeline I followed to go from raw OHRC data to a finished elevation map. I’ll walk through each stage — what it does, where things broke, and how I got around it.

I should note upfront: this pipeline is still evolving. The tools themselves are under active development, and some of my workarounds may become unnecessary as upstream fixes land. There may be minor inaccuracies in the results — I’m still validating against reference data where it exists. What I’m sharing here is what worked for me, as of now, to produce what I believe are credible results. I’ll update this as I learn more.

Fair warning: if you’ve stuck with me this far, thank you. In the sections below I walk through each step of the pipeline in some detail — what it does, where things broke, and how I got around it. If the nitty-gritty isn’t your thing, feel free to skip ahead to the results.

Step 1: Ingestion and SPICE Initialization

The first step converts OHRC’s archival PDS4 images into ISIS cube format, then attaches SPICE kernels. The SPICE system — originally developed by NASA’s NAIF — is what tells the software where the spacecraft was, how it was oriented, and where each detector pixel was pointing at the moment of capture. Without it, the image is just a grid of numbers with no spatial meaning.

This is where I hit my first wall.

The SPICE initialization step told me it couldn’t find attitude kernels covering my image dates. The images I was processing were from April 2024 — part of the recent polar imaging campaign I wrote about in my OHRC key insights analysis. The kernel files existed on PRADAN, but ISIS didn’t know about them because its internal kernel database hadn’t been updated.

So I downloaded the specific kernel files, placed them in the right directory, and ran the database regeneration tool. Sounds simple, right? It took me an entire day. The database tool has very specific expectations about how file paths are formatted internally — and if you get the format wrong, the lookup just silently fails. No error, no warning. It just doesn’t find the kernel. I tried everything before stumbling onto the correct path format buried in an ISIS developer discussion thread. One of those problems where the fix is a single line but finding it takes eight hours.

Step 2: Camera Model Generation — The Part I Had to Build Myself

This is where things get interesting, and where the pipeline diverges from what you’d see with a NASA mission.

For most missions ISIS supports — LRO, MRO, Cassini — generating camera models is a one-command affair. For Chandrayaan-2 OHRC, it just... doesn’t work out of the box. I spent a long time trying to figure out why.

The root issue is that the OHRC camera driver in ALE (the library that generates camera models) wasn’t included in the released version at all. It only existed on the development branch of the GitHub repository. So step one was installing ALE from source — already off the beaten path. But even after that, the standard camera model generation command failed because the driver expects spacecraft navigation data to be pre-loaded into memory, and the standard command doesn’t know how to find or load Chandrayaan-2’s data files automatically. For NASA missions, these paths are pre-configured. For Chandrayaan-2, they’re not.

I ended up writing a custom Python script that bridges this gap. It reads the navigation data file paths that ISIS recorded during the previous step, loads them into memory manually, and then invokes ALE’s Chandrayaan-2 driver directly to produce the camera model files that ASP needs downstream. It’s not elegant, but it works. And without it, the pipeline stops dead at this step.

There’s also an open pull request on ALE’s repository that includes geometric corrections for the OHRC driver. When that gets merged, the camera models should improve further. That’s the thing I love about open-source: I can see exactly what’s being fixed, contribute back, and everyone benefits.

Step 3: Bundle Adjustment — Where Everything Changed

Bundle adjustment refines camera positions by finding matching features across the stereo pair and minimizing the geometric error. ASP handles this automatically.

But this step produced the single most dramatic discovery in the entire project. And it came down to something that is absolutely not obvious from the documentation: which type of camera model you use changes everything.

There are two different camera model approaches in the ecosystem. The older ISIS-style model computes viewing geometry line by line. The newer Community Sensor Model (CSM) uses a continuous, interpolated representation. Both describe the same physical camera. In theory, they should give similar results.

In practice, the difference was staggering:

I sat there staring at the bundle adjustment log the first time CSM cameras produced 94,000 matches. I had been struggling for weeks with the ISIS camera path, getting ~100 matches, watching stereo tiles grind for 20 minutes each, wondering if something was fundamentally wrong with the data. Switching to CSM cameras — the ones generated by my custom script from Step 2 — turned a half-day ordeal into a 30-minute job.

This isn’t an incremental improvement. It’s nearly a thousand times more matches, and a 20-50x speedup in total processing time. It’s the difference between something that’s barely feasible and something you can run routinely.

I want to stress: both camera models come from the same open-source ecosystem. The CSM path just wasn’t the default for Chandrayaan-2, and getting it to work required the custom script. This is the kind of hard-won practical knowledge that only comes from actually running the full pipeline — and exactly the kind of thing I want to share so the next person doesn’t have to rediscover it the hard way.

Step 4: Stereo Matching

With the refined CSM cameras, the stereo matching step computes a dense pixel-by-pixel correspondence between the two images using the MGM (More Global Matching) algorithm — well-suited to pushbroom line scanners like OHRC. The software divides the overlap into tiles, processes them in parallel across CPU cores, then stitches and blends the results. From the matches, it triangulates each pixel pair into a 3D point in lunar coordinates.

This step mostly just ran. But “mostly” is doing some heavy lifting.

There was a naming inconsistency in ASP where the MGM algorithm produced output files with one name but the blending step expected a different name. A known bug — the workaround is creating file links for every processing tile. Annoying, but scriptable.

The bigger headache was that if even one tile out of hundreds fails or times out, the job scheduler kills the entire run. On a processing job that takes hours, that’s brutal. I learned to set generous timeout values, and more importantly, learned how to resume from the last completed stage rather than starting over. I lost a few runs before figuring that out.

Step 5: DEM Generation

The final computational step interpolates the irregular 3D point cloud into a regular gridded elevation map.

One thing I learned the hard way: let the tool choose the grid resolution automatically. My first instinct was to force 25 cm spacing to match OHRC’s native pixel size. But the tool correctly warned me that the point cloud wasn’t dense enough to support that — the actual information content after stereo matching and triangulation supports about 30-35 cm. Forcing a finer grid just interpolates between points and gives you a false sense of resolution. I appreciated the honesty.

The output is three products:

• DEM — elevation values in meters relative to the lunar reference ellipsoid

• Orthoimage — the image draped onto the DEM surface, removing terrain distortion

• Error map — per-pixel triangulation error, showing where the 3D reconstruction is most and least reliable

Step 6: Visualization & Normalization

One last surprise that tripped me up: lunar elevation values are all large negative numbers. The surface typically sits 1-2 km below the reference ellipsoid (which has a radius of 1737.4 km), so a typical DEM might range from -1750 m to -1565 m. Most 3D viewers and even some GIS tools completely choke on this. The fix is simple — shift values into a positive range for visualization.

The Uncool Stuff That Wasted the Most Time

I’d be dishonest if I didn’t mention the platform-level issues that had nothing to do with planetary science but consumed days of debugging:

Running this on an Apple Silicon Mac meant dealing with the fact that ISIS operates under processor emulation while some of its dependencies get installed as native packages. When they don’t match, things crash with cryptic library loading errors. Figuring out that this was an architecture mismatch — and not a corrupted installation — took me longer than I’d like to admit.

Then there was the fact that ASP installs its own set of system tools that can silently override the ones from the Python environment. Every script invocation broke until I figured out the PATH ordering was wrong. Not a science problem. Not even really a software problem. Just... computers being computers.

These things don’t show up in papers. But they’re a real part of making any of this work, and they’ll absolutely stop someone trying to reproduce the results if they’re not warned.

The Result

After months of understanding the data, weeks of building and debugging the pipeline, and over 24 hours of final processing on a high-performance machine, the output is a Digital Elevation Model of the Shiv Shakti Point region at approximately 30 cm per pixel.

Metric Value Horizontal resolution ~0.30 m (30 cm per pixel) Vertical accuracy ~40–50 cm Median triangulation error 8 cm Coverage 2.18 x 2.24 km Valid pixels 91.6%

For context: the best publicly available lunar elevation data from NASA’s LRO LOLA achieves roughly 1 meter at selected sites, and about 30 meters globally. This OHRC-derived DEM is roughly 3x finer than LOLA’s best, and over 100x finer than global coverage.

At this resolution, you can see individual boulders. Meter-scale terrain features — subtle slopes, small craters, regolith texture — become clearly visible in the elevation data.

This is, to my knowledge, among the highest resolution open elevation datasets produced from Indian lunar mission data. And it was built entirely from publicly available Chandrayaan-2 imagery, using open-source tools, by one person.

Lastly, I want to be transparent here: the pipeline is still being refined, and there may be minor inaccuracies as I continue to validate against reference datasets. The numbers above represent my best current results. As the upstream tools improve — particularly the geometric corrections in ALE — I expect the accuracy to improve as well.

Why This Matters for What Comes Next

India’s Chandrayaan-4 mission aims to demonstrate lunar regolith sample collection and return. That’s an extraordinarily demanding task — not just the propulsion and robotics, but the site selection. You need to know not just where the flat spots are, but how flat they actually are. Whether there’s a 30 cm boulder hiding in what looks smooth at coarser resolution. Whether the local slope exceeds the lander’s tilt tolerance. Whether the terrain between the lander and the sample site is actually traversable.

A 30-meter elevation model can’t answer those questions. A 1-meter model gets close. A 30-centimeter model can.

As I discussed in my analysis of the IM-2 Athena landing, high-resolution data plays a dual role: pre-landing site characterization and post-landing forensic reconstruction when things don’t go as planned. The scuff marks, the drag patterns, the tilt of a toppled lander — all of these become analyzable when you have both imagery and elevation data at sub-meter resolution.

The raw data for more of these maps already exists. Chandrayaan-2’s OHRC has been capturing stereo pairs across the lunar surface for over five years now. The polar imaging campaign of early 2024 — which I documented in my OHRC operational insights — produced dozens of observations near the south pole in preparation for LUPEX. The imagery is there. The navigation data is there. The tools are there.

What’s Next

This first release covers a single site. The OHRC archive contains stereo pairs across multiple locations — polar regions, mid-latitude sites, areas of geological interest. I plan to process additional sites wherever viable stereo coverage exists and make the resulting elevation products available to the wider community. Soma — the lunar data portal I’ve been building — will be the primary way to access and explore these products once I release it.

I also plan to contribute back to the open-source tools that made this possible. The custom scripts, the workflow documentation, the workarounds — all of it should flow upstream so the next person doesn’t start from zero. There’s already an open pull request improving the OHRC camera model, and I’d like to help get that across the finish line.

The open-source planetary science community — at USGS Astrogeology, NASA Ames, and the universities contributing to ISIS, ASP, and ALE — has built something genuinely remarkable: a toolkit that lets anyone with enough persistence produce science-grade data products from planetary mission data. That philosophy of openness is what made this work possible. I hope ISRO, in time, comes to embrace a similar approach — not just releasing raw data, but investing in open tools and open data products that let the global community build on India’s remarkable achievements in space. India built the best camera at the Moon. Let’s make sure the world can use what it sees.

The elevation maps discussed in this post were built using Chandrayaan-2 OHRC data from ISRO’s PRADAN portal, processed with ISIS (USGS), the Ames Stereo Pipeline (NASA), and ALE (USGS). This is an evolving effort — results will be updated as the tools and validation improve.

References:

[1] Chowdhury, Arup Roy, et al. “Orbiter High Resolution Camera onboard Chandrayaan-2 Orbiter.” Current Science, vol. 118, no. 4, 2020, pp. 560-565.

[2] Amitabh, Ashutosh Gupta, K. Suresh, et al. “High Resolution DEM Generation from Chandrayaan-2 Orbiter High Resolution Camera Images.” LPSC 2021.

[3] Amitabh, K. Suresh, et al. “Terrain Characterization of Potential Landing Sites for Chandrayaan-3 Lander using Orbiter High Resolution Camera (OHRC) Images.”

[4] Beyer, R. A., Alexandrov, O., and McMichael, S. “The Ames Stereo Pipeline: NASA’s Open Source Software for Deriving and Processing Terrain Data.” Earth and Space Science, 5, 2018.

~FIN

A Prelude.

I’ll be honest: balancing a full-time day job with non-paid yet deeply fulfilling work is tough. It was two years ago, on the eve of India’s biggest achievement of the decade, that I found my passion for publicly sharing the work I’d quietly pursued outside of my daily grind reawakened.

India rightfully declared the day Chandrayaan-3 touched down at Shiv-Shakti Point as “National Space Day” for posterity. To me, it marked the day I rekindled my own curiosity—and what followed has been quite a journey. I launched this blog, dove deeper into lunar imagery, and started analyzing it using whatever techniques I picked up over the years. Whenever time allowed, I’d share insights, and almost incidentally, I wound up being the first to spot Japan’s SLIM lander and, more recently, Intuitive Machine’s Athena in archival data released by ISRO at ISSDC.

People often ask how I manage to do what I do. Some think it must be easy. Admittedly, it’s gotten somewhat “easy” for me now. Still, despite the many tools I’ve personally cobbled together to make my life a tad simpler (because ISRO, for reasons best known to them, refuses to open-source their own tooling—though they often benefit from others that do!), it always comes back to good old manual effort: hunting for patterns in images, trying to spot possible locations of non-natural objects on the Moon’s surface in datasets (especially from OHRC) released by ISRO, NASA, or other space agencies.

On this second anniversary, I want to open the doors to a bit of my workflow and share the joy with fellow “commoners.” Today, I’m releasing the Lunar Data Explorer—a portal optimized for “serving” the high-resolution lunar imagery (among others) made public by space agencies. Now, anyone can self-explore my curated data and “find” non-natural objects like the Chandrayaan-3 lander or Athena on their own, and share their findings with the world!

Lunar Data Explorer

The primary goal of this portal is education. I want to give the general public the opportunity to explore and research for themselves. Naturally, all image copyrights remain with their respective owners. Please remember to always attribute the images and respect the original creators’ work. If you use the “Capture View” feature of the portal, the appropriate attribution will be displayed automatically.

I hope to keep releasing more curated content in the coming weeks and months. If you have a favorite dataset or suggestion, you’re welcome to leave a comment below this post—I’ll do my best to include it in an upcoming release slot. In the meantime, feel free to explore and enjoy the portal!

Subscribe now

Below, you’ll find a short explainer on how to use the portal. Otherwise, it should be pretty straightforward. If you have any questions or comments, don’t hesitate to reach out. The portal is still in its early days, so there may be a few rough edges—some things might not work as expected. Suggestions are always welcome; I’ll do my best to address them. Leave a comment! 🙂

Cloud-Optimised Lunar Data explorer

The Lunar Data Explorer—or simply “Explorer”—is a straightforward, browser-based app that lets you explore high-resolution images captured by instruments like OHRC onboard Chandrayaan-2. Normally, working with these massive images can be a nightmare for your browser; it’s nearly impossible without hefty downloads! But Explorer is optimized specifically for a seamless browsing experience. What does that mean in practice? Instead of downloading an entire image strip (a typical high-res strip can easily exceed one and a half gigabytes!), the portal fetches only the portion you want to view—on the fly—while the rest of the image stays in low-res.

This is possible thanks to a browser-efficient image format that’s highly optimized for the cloud: Cloud-Optimized GeoTIFFs, or COGs for short. The technical details, specifications, and format intricacies deserve their own deep dive—I’ll save that for a future article where I’ll cover how I created the COGs for the lunar imagery in depth.

In short, Explorer serves these COGs, which power the entire portal. That’s why you can browse these images even over low bandwidth (trust me, I’ve tested it!). And, yes, for the data-hungry out there, there’s even a toggle to load higher-resolution images—if your internet connection can handle it.

How to Use the Explorer

While the usage is pretty straightforward, here are some features of the Explorer to help you get started:

• Select Image: At the top, you can choose from a list of available lunar images to explore—just use the dropdown menu.

• Toggle High Quality: Switch on “High Quality” if you’ve got a faster internet connection and want to load images at higher resolutions.

• Capture View: Use the “Capture View” button to take a screenshot of your current viewport; this will automatically include proper image attribution.

• Viewport Minimap: The small panel at the bottom left acts as a minimap, helping you navigate and keep track of which section of the lunar image you’re viewing.

• Metadata Panel: On the right, you’ll find detailed metadata for the current image—mission name, instrument, creation date, and filesize. You can also download the original image (eg: look for the “via Pradan” link).

• Expanded Metadata: Additional data such as observation details and geometry can be accessed via expandable sections.

• Credits: Image credits and attribution are always displayed to give proper recognition to source data and contributors.

Feel free to play around and explore—each feature is designed to make your lunar imagery journey as smooth and enjoyable as possible!

~FIN

The IM-2 mission, part of NASA's Commercial Lunar Payload Services (CLPS) program, launched on February 26, 2025, at 7:16 p.m. EST (00:16 UTC on February 27) aboard a SpaceX Falcon 9 rocket from Launch Complex 39A at NASA's Kennedy Space Center in Florida. The Nova-C lander, named Athena, carried NASA science instruments, including a drill and mass spectrometer for detecting lunar volatiles, along with commercial payloads like a micro-rover and a hopping drone. Following liftoff, Athena separated from the rocket's second stage about 45 minutes later and established communication with ground controllers, confirming it was on course for the Moon. The launch also included secondary payloads, such as NASA's Lunar Trailblazer orbiter, which deployed successfully en route

During its approximately eight-day transit to the Moon, Athena performed several trajectory correction manoeuvres to refine its path, with the first occurring shortly after launch and subsequent burns ensuring precise alignment for lunar orbit insertion.

On March 3, 2025, the lander executed a 492-second main engine burn to enter a circular low lunar orbit at about 100 km altitude, where it spent roughly three days a total of 39 Lunar orbits conducting system checks and imaging the surface. Flight controllers at Intuitive Machines' Nova Control in Houston monitored the spacecraft's health, calibrating navigation cameras and preparing for descent, while Athena captured detailed images of the lunar south pole region near its target site.

Unfortunately, just as with its predecessor Odysseus from the IM-1 mission, the Nova-C lander Athena for IM-2 experienced significant issues during its final descent. A faulty laser altimeter, compounded by dust interference, led to inaccurate altitude readings, causing the spacecraft to descend at a higher-than-optimal speed of approximately 6 meters per second vertically and 2 meters per second horizontally. This resulted in a hard landing that tipped Athena over on its side inside a shadowed crater at Mons Mouton, roughly 1,300 feet (400 meters) from its intended target site near the lunar south pole at -84.7906, 29.1957 in 20m shallow crater.

A ‘Not-so’ Optimal Landing

Just a few hours after the Lunar Reconnaissance Orbiter Camera (LROC) captured its initial oblique view of the ill-fated IM-2 lander Athena on March 7, 2025, the Orbital High-Resolution Camera (OHRC) onboard the Chandrayaan-2 orbiter obtained imagery from its own vantage point. This additional data provides new insights into the final moments of Intuitive Machines’ Nova-C Athena mission and strongly supports the initial post-mortem assessments of the lander’s tipped-over state in a shadowed crater near Mons Mouton at the lunar south pole.

The Chandrayaan-2 images, taken on March 7, 2025, at 21:31 UTC—just four and a half hours after the LROC capture—depict Athena’s final resting place: hard-landed in a shallow crater, with its sideways orientation confirming operational loss mere hours into its operations. A follow-up image, acquired during the next orbital pass at 23:30 UTC, further documents the aftermath and surrounding surface context.

During the terminal descent and landing phase, Athena autonomously touched down but came to rest on its side in a shadowed crater, not in the upright configuration originally planned. The IM-2 team activated payloads immediately after landing, gathering and transmitting as much data as possible before the lander lost power due to its sideways position and limited sunlight.

The failure of the IM-2 Athena lander was attributed to its faulty laser altimeter and according to official post-mission reviews, during the descent the laser altimeter—which is critical for measuring altitude and controlling the speed and timing of the final landing—experienced significant “signal noise and distortion.” This interference prevented the system from providing accurate distance-to-ground readings. As a result, Athena’s landing software incorrectly believed it was still higher above the surface and maintained a higher-than-safe descent speed.

This fault in altitude data likely caused Athena to contact the lunar surface with excessive velocity, resulting in the lander tipping onto its side and either skidding or rolling into its final resting orientation within the crater. While the post-mission technical review frames this as a ‘probable scenario’, close analysis of the high-resolution Chandrayaan-2 OHRC images—captured by ISRO’s most capable lunar camera—supports this conclusion with a substantial degree of certainty.

From the 25 cm–per‑pixel high‑resolution imagery, the remains of Athena are plainly identifiable within a ~20 m shallow crater, with the landing legs discernible in the debris silhouette indicated by the arrow. More critically, immediately adjacent—near the smaller neighbouring crater—there are clear, linear soil disturbances consistent with “drag” marks. These surface traces are not random albedo variations; they exhibit coherent directionality and morphology expected from a low-angle, lateral motion following an off‑nominal contact.

Taken together, these features strongly indicate Athena appears to have contacted the surface at excessive velocity, tipped, and then slid or dragged before coming to rest. The orientation of the scuffs and redistributed regolith supports an approach vector from the north-east (NE) toward the final position. While this interpretation must be framed cautiously pending full photogrammetric reconstruction and shadow-model verification, the visible evidence in this dataset materially strengthens the “hard-contact followed by lateral displacement” scenario over a clean, stationary touchdown.

This assessment is in line with Intuitive Machines CTO Tim Crain’s observation on the images I present here

(…) the engine plume surface interaction streak and the first contact of the landing gear.

Importance of High resolution Cameras in LO

High‑resolution lunar‑observation (LO) orbiters are reshaping how we prepare for, execute, and understand landings. Instruments like Chandrayaan‑2’s OHRC deliver technical clarity and public transparency that mission press releases rarely provide. Before touchdown, decimeter‑class imagery maps hazards, tightens target ellipses, and de‑risks descent by revealing boulders, slopes, and regolith textures that coarser datasets miss.

Afterward, the same camera enables independent, ground‑truth reconstruction—pinpointing the landing site, identifying hardware and debris, and reading surface signatures such as plume scour, skid or drag marks, and first‑leg‑contact points. This dual role—pre‑landing safety assurance and post‑landing forensic verification—not only informs ISRO’s planning and anomaly reviews; it also elevates global mission accountability and accelerates shared learning across the lunar community.

These capabilities provide not just public transparency, but also a crucial operational advantage for ISRO itself. As a space-fairing nation, India prepares for Chandrayaan-4 and the LUPEX mission, the OHRC’s data is indispensable for analyzing the real outcomes from other missions such as this one and avoiding repeated, costly mistakes.

For ISRO and for India, where every lunar attempt must count due to tight constraints and a philosophy of frugality and “success on the first try” Key insights derived from OHRC are not just helpful—they are absolutely essential!

Athena: a story of partial success

The mark of success in lunar landings isn’t sticking the touchdown call on a livestream—it’s standing the vehicle up, powering it stably, and executing the surface plan to specification. Anything less is, at best, a partial so yes — I call Athena, a story of partial success. Congratulations the entire team of Intuitive Machines! you folks deserve all the praise for making a touchdown — a hard-landing with a partial operations for a day is still better than a crash.

In prior articles, I’ve argued that the bar for calling lunar landings “successes” has been lowered to the point of distortion—driven by commercial spin and echoed uncritically by much of the press. Odysseus (IM‑1) is a case in point: despite the non-deserving unqualified success it was hailed as a ‘mark of success’. A soft-landing dynamic model of a legged lander gives more importance to the stability as a primary criteria for a successful soft-touchdown. I’m happy that this time the coverage has been more restrained—fewer blanket “success” proclamations in the face of obvious stability and operability shortfalls.

While this mission didn’t achieve all of its objectives for NASA, the work that went into the payload development is already informing other agency and commercial efforts

(…)

While we’re disappointed in the outcome of the IM-2 mission, we remain committed to supporting our commercial vendors as they navigate the very difficult task of landing and operating on the Moon.

— NASA

In conclusion, I wish the entire team every success — ich drücke meine Daumen — and I sincerely hope the third time’s the charm.

~FIN

It's been about a year now since I launched this blog in March 2024, driven by my passion for 🌓 Lunar Exploration and the shared curiosity about humanity’s future beyond our home planet.

Initially, I realised my deep dives and threads on X deserved a more permanent home, prompting me to explore this format a bit more seriously.

A year later, balancing full-time paid work, personal commitments, and maintaining consistent updates has taught me a lot. Regular daily updates? Tried it—couldn’t sustain it. Weekly newsletters? Same story. There are already fantastic sources for keeping up with rapid developments, especially Lunar missions — Spacenews, Moon-Monday, and Orbital Index to name just a few. (Feel free to suggest more in the comments!)

What you can expect from me moving forward are thoughtful, longer-form articles, summaries, monthly or may be weekly or whenever inspiration strikes, that isn’t necessarily yesterday’s moon landing. I promise authenticity and genuine effort rather than frequency alone.

If this resonates with you, subscribing ensures you won’t miss a thing—new content delivered straight to your inbox.

Towards sustainable blogging

I debated between Ghost and Substack quite a bit before finally choosing Ghost. It was my primary platform for blogging, and at the time it felt right—it still does.

Ghost is fantastic for writing: the direct support for markdown, the intuitive '/' dynamic menu, and the bookmarking features have been extremely helpful. That said, it’s not exactly cheap. The pro yearly subscription alone costs me $108, on top of domain expenses.

Originally, I hoped this blog would evolve into a regular, sustainable newsletter, justifying the costs. But I’ll be honest—in the battle between paid and unpaid work, the former almost always wins, especially in the beginning. I’m trying to change that and, rather than force myself into unsustainable commitments, I decided to choose a platform and cadence that genuinely fit where I'm at right now.

Though I ultimately chose Ghost, Substack is a solid #2. At the time, I found Substack slightly inferior for my needs, but I genuinely appreciated their strategy: "We get paid when you do." Inspired by this clarity, I’ve decided not to paywall any of my articles, not then, not now. Instead, I ask you my reader, the subscriber, to pledge your support if you find value in what I’m creating.

Subscribe now

Maybe I'll end up enabling paid support eventually if enough people truly believe in the content here—let's see how it unfolds. I’m hopeful and looking forward to another year of good articles. I hope you enjoy reading them as much as I enjoy writing them.

In the days, I'll be busy setting up my Substack and migrating everything from Ghost before resuming my posts. The first step is moving my domain here, so if you're reading this, moonandbeyond.blog would’ve already migrated to moonandbeyond substack or at least in process of migration. Honestly, the migration has been a bit bumpy, but I've managed it. Occasionally, you might see a broken link or image in my older posts—if you do, please comment below the post or email me directly; I’ll get it fixed promptly.

That's it for now—see you around in my next post.

Per aspera ad lunam!

Again, thanks for being here—and do spread the word if you enjoy the journey!

Share Moon and Beyond

~FIN

Just hours ago, SpaceX's Falcon 9 successfully deployed two lunar landers, marking the beginning of this year's efforts in lunar exploration. Firefly's Blue Ghost Mission 1 and ispace's Mission 2, part of the HAKUTO-R Venture Moon program, are now embarking on ambitious journeys to attempt lunar landings later this year.

These are among the first lunar landers of the year, with Intuitive Machines' IM-2 Athena targeting a launch at the end of February 2025. A follow-up mission, IM-3, is also anticipated to launch in early 2026, according to reports by NSF's Jeff Foust.

Following the setback of Peregrine's failure almost a year ago, Astrobotic has been diligently advancing its efforts toward lunar exploration. The company is reportedly making 'serious progress' in preparing for the launch of its Griffin Mission One, a pivotal mission slated for later this year. This mission aims to achieve a significant milestone by targeting a landing at South Pole. I will cover this in detail towards the launch of it.

On the other hand, Blue Origin is gearing up for its pathfinder mission, MK1, as part of its Blue Moon lunar lander program, with a launch planned for 2025. The MK1 is a robotic cargo lander engineered to deliver up to 3 metric tons of payload to any location on the lunar surface. The MK1 is specifically designed to bridge the gap between smaller CLPS landers and larger cargo vehicles including the ability to act as surface power source for comm relays and Position, Navigation, and Timing (PNT) capabilities.

Mission Profiles of the Duo

The mission profiles of these early 2025 landers set the stage for an ambitious year in lunar exploration. Firefly's Blue Ghost Mission 1 (BGM1) takes a relatively shorter route, aiming to complete its journey in about 45 days to attempt a landing at Mare Crisium, or the 'Sea of Crises.' Meanwhile, Japan's Resilience Lander is following a longer trajectory, taking approximately 4 to 5 months to reach the Moon, where it plans a landing at Mare Frigoris, or the 'Sea of Cold.' Notably, the RESILIENCE Lander's mission path mirrors that of JAXA's SLIM, which successfully achieved a soft touchdown last year.

Both landers target the Near-Side of the Moon, contrasting with the milestone set by last year's Chang'e 6 mission, which retrieved lunar regolith from the Far-Side.

Success 'criteria' of the Missions

What truly defines the success of a lunar mission? At first glance, the answer seems obvious: to land without breaking into pieces right? But is it really that simple? The more you ponder, the more nuanced it becomes. Is success measured by achieving a soft and gentle landing? By landing legs remaining fully intact? By the lander being operational immediately upon touchdown, or is a delay of a few days acceptable? These questions swirl in my mind, especially when reflecting on last year’s events, where some missions challenged traditional benchmarks for success

Media outlets like Space, Ars Technica, including NASA have often overlooked these nuances, framing any form of lunar landing—even one involving broken legs or a non-operational lander—as a mark of success, particularly from a commercial perspective. This approach reflects the increasing commercial pressures within the space industry, where even partial achievements are frequently marketed as "unqualified successes." This narrative raises questions about how success is defined and whether such standards dilute the scientific rigor traditionally associated with lunar exploration milestones.

This leniency, and the accompanying duplicity, have been called out by fellow Moon writer Jatan, who aptly questions

If we truly want sustainable lunar exploration, we also need to be true to ourselves. Do we desire our Moonbase to be built on a house of cards or cemented concrete?

To take a more scientific approach in determining whether a landing qualifies as a soft touchdown or a hard landing, I presented my thoughts and analysis on Intuitive Machines, "Odie." Stability must be regarded as a non-negotiable criterion for defining a soft landing. A truly soft touchdown ensures that the lander remains upright and structurally intact, capable of performing its intended operations without compromise.

Additionally, defining a successful mission requires clarity. A successful mission should mean that the lander becomes operational—at least once during its lifetime. This does not imply continuous activity throughout; rather, it reflects the lander fulfilling its key objectives, even if recovery occurs after challenges. JAXA's SLIM mission exemplified this, surprising many with its ability to recover and operate after enduring the harsh conditions of a lunar night.

In my view, a soft landing must guarantee stability, and a successful mission must involve operational activity—whether immediately or after recovery. These criteria ensure that we evaluate lunar missions with scientific rigor and fairness, providing clear and consistent benchmarks for success. Without such standards, we risk distorting achievements and undermining the progress of lunar exploration.

Over and above that, Japanese missions have demonstrated a commendable commitment to clear and specific success criteria. Over its entire lifetime, SLIM demonstrated a clear and structured approach to success, gradually meeting and exceeding its criteria. Starting with the minimum requirements, the mission progressed to fulfil additional objectives, with only minor corrections along the way. This step-by-step achievement underscores the Japanese commitment to transparent and precise mission evaluation, setting a strong example for future lunar exploration.

Following a similar approach to JAXA, ispace has outlined 10 clear milestones for its mission, covering every phase up to and including its lunar touchdown.

At the time of writing this article, ispace has already achieved the 3rd milestone in its 10-point mission plan. Meanwhile, its counterpart, Blue Ghost, has successfully established communication links with its ground station and completed its initial testing of NASA's RadPC payload, marking significant progress for both missions.

Landing Sites

Firefly's Blue Ghost Mission 1 (M1) is targeting a landing site with-in a 50m landing radius centered at 18.560N, 61.807 E. The site is close to Mons Latreille within Mare Crisium, a prominent basin in the northeast quadrant of the Moon's near side. Formed by early volcanic eruptions and subsequently flooded with basaltic lava over 3 billion years ago, Mare Crisium offers a rich geological history ideal for studying the Moon's ancient volcanic processes and crustal composition [1].

The site's geology also makes it a prime location for subsurface drilling operations. Instruments like LISTER (Lunar Instrumentation for Subsurface Thermal Exploration with Rapidity) will measure the Moon's internal heat flow at larger depths of 2–3 meters, providing insights into its thermal history. Additionally, Mare Crisium's regolith properties are key for understanding lunar soil characteristics and their interaction with the solar wind, furthering our knowledge of the Moon's surface environment and its evolution.

Hakuto-R Mission 2 (M2), featuring the RESILIENCE lander, targets a site in Mare Frigoris (Sea of Cold) at 60.5°N, 4.6°W. Located in the northern hemisphere of the Moon, Mare Frigoris is an expansive basaltic plain with a different geological context compared to Mare Crisium.

While Firefly’s mission focuses on precise thermal measurements and regolith interactions, Hakuto-R’s target offers a broader look at the evolution of basaltic plains in the northern regions. The site’s location provides a distinct environment, helping to expand knowledge of the Moon’s diverse geological history.

It's just the beginning..

The two missions, Firefly’s Blue Ghost Mission 1 and Hakuto-R Mission 2, are currently en route to the Moon, targeting distinct landing sites with different timelines. These ongoing missions showcase complementary approaches to lunar exploration, reflecting the growing diversity and ambition in lunar science.

While I wait for the new lunar missions scheduled for the coming months, I will closely monitor the progress of these landers. In the weeks ahead, I’ll provide updates on their journeys, including detailed terrain analyses and mission insights—just as I did for Intuitive Machines’ IM-1 mission. Stay tuned for the coverage as these missions attempt to reach their landing sites and unveil new lunar discoveries!

~FIN

[1] Sliz, M. U., & Spudis, P. D. (2016). New geologic map of the lunar Crisium basin. 47th Lunar and Planetary Science Conference, Abstract #1678 https://www.hou.usra.edu/meetings/lpsc2016/pdf/1678.pdf

In my previous posts I announced VayuVani for Independent Satellite communication where I listed and attempted to explain my thoughts in the current status-quo of "Open-source" LoRa ground-station projects. I explained my reasons on venturing a new project.

My primary goals for VayuVani still remain

Enable Truly Independent Operation:

Democratize LoRa Technology:

In this post, I'd like to explain and expand on what makes VayuVani tick, while saving the technical nitty-gritty for later posts.

One of VayuVani's standout features is how it handles privacy and puts you in control. As I mentioned before, VayuVani works completely offline while keeping operations local. I built VayuVani around three key design principles that make this possible:

Operationally disconnected

The system operates completely independently of internet connectivity, ensuring all data remains strictly local. This isn't meant as a fallback feature - it's the core design principle that ensures complete data sovereignty.

The ground station processes all satellite signals locally, performs decoding operations on-device, and stores data without any external dependencies. This approach eliminates potential security vulnerabilities associated with network transmission and prevents unauthorized access to sensitive communications.

User-Centric Control Architecture

VayuVani fundamentally reimagines ground station control by placing complete operational authority in the users' hands. This comprehensive control manifests across multiple aspects of the system's operation.
At the RF level, users exercise complete authority over their radio parameters. This includes precise control of frequency selection across supported bands, with the ability to fine-tune bandwidth configurations from 62.5 kHz to 500 kHz. The system allows detailed optimization of spreading factors, coding rates, and preamble lengths - all crucial parameters for achieving optimal satellite communication.

As shown in the dashboard interface, users can adjust these parameters in real-time, with settings like SF8.00 and coding rate 6.00 being typical for LEO satellite reception.

Satellite tracking capabilities extend beyond simple pass predictions. Users can implement their own tracking algorithms, manage TLE data independently, and switch between automatic and manual tracking modes. The system's tracking interface provides real-time visualization of satellite positions and trajectories, allowing operators to make informed decisions about satellite selection and tracking strategies. System extensibility forms another cornerstone of VayuVani's user-centric design.

The architecture supports adding new satellite, developing custom decoders and extending the system. This flexibility allows operators to adapt their ground station to specific requirements, whether for research, education, or experimental purposes.

Data Sovereignty

VayuVani fundamentally reimagines data handling in satellite communications through its real-time, locally-controlled architecture. Unlike networked systems that mandate central control, VayuVani operates as a truly independent entity, establishing a direct, secure pipeline from signal reception to analysis.

When the ground station receives signals from a tracked satellite, the raw data is transmitted in realtime to the ground station application. This real-time transmission ensures that higher data reception rates are possible because of the lack of any further processing on the ground station itself.

The application which receives only raw packet data then performs local decoding operations, transforming raw satellite signals into decoded packet data - all without touching the internet or external services. The decoded data is further processed into human readable data.

The decoded data including the raw data are stored locally on the app on the user’s machine. This data is then directly used in VayuVani's Packet Dashboard, creating a comprehensive local repository of satellite communications. This dashboard serves as a analytical tool, offering insights into:

• Signal quality metrics

• Reception patterns across different satellites

• Temporal analysis of reception quality

• Station performance metrics

• Satellite-specific reception windows and optimal tracking periods

This local-first approach ensures:

• Complete data ownership without external dependencies

• Real-time processing and visualization of satellite data

• Historical performance analysis for optimization

• Independent decision-making based on actual reception data

• Freedom to implement custom analysis methods

The system's autonomous nature extends beyond mere data collection. Users can analyze reception patterns to identify optimal tracking windows, adjust radio parameters based on historical performance, and make informed decisions about station configurations - all through direct interaction with their locally stored data.

Whether tracking PICO-1B-3 at 436.07 MHz or experimenting with new satellites, every aspect of data handling remains under direct user control. This comprehensive data sovereignty transforms VayuVani from a simple receiver into a powerful analytical platform, enabling users to understand and optimize their satellite communications while maintaining absolute control over their data and operations.

Applications Benefiting from VayuVani's Design

This unique approach particularly benefits applications requiring private communication channels and independent operation capabilities, such as:

STEM Education: Students and educators can build affordable ground stations for hands-on satellite communications learning. This enables:

• Student-led satellite tracking projects using open-source firmware and control server

• Custom decoder pipeline for the transmitted packets

• Direct satellite communication experience without internet dependency

The custom decoder pipeline allows students to develop their own standard decoder for the receiving and decoding the raw packets directly in VayuVani. VayiVani out of the box support Kaitai structs as a decoding format for the

Research Independence: Academic labs and independent researchers can conduct satellite studies with complete data sovereignty. The detailed metrics and analysis tools enable thorough research while maintaining full control over data collection and methodology.

Weather Balloon Experiments: VayuVani's versatile ground stations support both satellite and ground-based transmitters, making weather balloon experiments a perfect use case. The setup includes:

• Non-VayuVani transmitters mounted on weather balloons

• Custom decoder pipeline for balloon-specific signals

• Network of VayuVani ground station receivers

This enables atmospheric data collection in remote areas beyond internet coverage, demonstrating VayuVani's dual capability for both space and terrestrial signal reception.

Hybrid Relay Stations: VayuVani's hybrid communication infrastructure creates a resilient mesh network through interconnected ground stations. Each station functions as both transmitter and receiver, with dedicated decoders handling:

• Signal reception from satellites and ground transmitters

• Local processing and data aggregation

• Re-transmission to extend network reach

• Routing through multiple relay points

• Offline operation without internet dependency

The system enables:

• Extended coverage in remote areas

• Redundant communication paths

• Efficient data distribution across the network

• Seamless integration of satellite and terrestrial signals

• Autonomous operation of each relay point

This hybrid architecture, highlighted in the image with three interconnected stations, demonstrates VayuVani's capability to create robust communication networks in areas lacking traditional infrastructure.

Limitations and Future Directions

While VayuVani represents a significant advancement in amateur satellite communications, it's important to acknowledge its current limitations and potential areas for future development:

1. Local Network Dependency: The ground station and dashboard must operate on the same local network to maintain privacy and user control, making remote operations challenging without additional network configuration.

2. LoRa-Only Reception: Currently limited to satellites using LoRa modulation, preventing reception of other common satellite protocols and limiting the range of accessible satellites.

3. Hardware Constraints: Requires specific LoRa hardware (operating in 433 MHz or 868 MHz bands) and compatible computing platforms, which may limit deployment flexibility.

4. Operational Range: Single ground station can only track and decode one satellite at a time, with reception quality dependent on local conditions and satellite elevation.

5. Data Management: Local storage and processing requirements mean users must manage their own data retention and backup strategies.

Future Directions

To address these limitations and further enhance VayuVani's capabilities, several future directions can be explored:

1. Privacy-Preserving Remote Operations: Developing a secure relay network architecture that enables remote station management while maintaining VayuVani's core principle of user data sovereignty and operational independence.

2. Community Ground Station Network: Creating a framework for community-operated ground stations, enabling collaborative satellite tracking while ensuring each station maintains complete local control over their data and operations.

So what can you do now?

Get Involved! VayuVani needs community support to grow:

• Deploy more ground stations to expand coverage

• Develop decoders for different satellite signals

• Share the project with radio enthusiasts and STEM communities

For more information, visit vayuvani.com or just leave a comment here and I will reach you out.

I'm excited to introduce VayuVani, a project born out of personal frustration and a vision for genuinely independent satellite communication. VayuVani (/ˈʋɑːjuː ˈʋɑːɳiː/ spelled as Vaayu-Vaaani) combines two Sanskrit words: "Vaayu" (वायु) meaning Air, and "Vaani" (वाणी) meaning Voice or Music, embodies my mission to give voice to the signals traveling through the air, leveraging the power of LoRa technology for long-distance communication.

What is VayuVani?

VayuVani is an open-source project designed to empower individuals to create and manage their own LoRa ground stations for satellite communication. It's a comprehensive system that allows for the independent operation of ground stations, enabling users to capture, decode, and analyze LoRa signals from satellites without relying on external services or centralized control. VayuVani aims to provide a flexible, privacy-focused, and user-controlled alternative in the world of amateur satellite communication.

Why I Created VayuVani

My journey began with a seemingly simple yet insurmountable roadblock: I couldn't register for a Telegram account due to issues with my phone number. In the world of LoRa ground stations, this seemingly unrelated issue became a major obstacle. Popular platforms like TinyGS, while excellent in many ways, rely heavily on Telegram for operations. Without an account, I found myself completely locked out of a world I was eager to explore.

But my frustrations didn't end there. Even with a fully functioning ground station, I discovered that TinyGS could block a user's public IP address, effectively rendering their station inoperable. This level of dependence on external systems and potential for disconnection was deeply concerning. I realized that no matter how well you build your ground station, these external factors could prevent you from operating it.

What's more, when I reached out to the developers about these issues, I was met with silence and, I am not the only one in this situation. The community was amazing and supportive, but the lack of response or remedy from the developers left me feeling abandoned and frustrated. As a newcomer to the field, I felt helpless, realizing that control was concentrated in the hands of a few main developers who seemed to be selective about what or whom to respond to. To compound the problem, there were numerous occasions when the central TinyGS server was down due to resource saturation or maintenance by their providers, further hampering operations.

These experiences made me realize that I needed a truly independent solution – one that doesn't rely on external platforms or centralized servers for basic functionality.

My Vision for VayuVani

With VayuVani, I'm aiming to:

1. Enable Truly Independent Operation: I'm building a system that allows you to manage and receive satellite packets completely offline, ensuring your privacy and independence.

2. Democratize LoRa Technology: By making LoRa technology accessible to everyone, I hope to foster innovation and expand the possibilities of long-range communication.

3. Build a Responsive Community: I believe in the power of shared knowledge and responsive support. VayuVani isn't just a technology; it's a community where your voice matters.

4. Ensure Offline Functionality: In a world where internet connectivity can be unreliable or compromised, I've ensured that your ground station can function entirely offline.

5. Bridge the Connectivity Gap: By enabling independent satellite communication, we can bring connectivity to underserved areas and empower communities.

What's in it for You?

By joining the VayuVani project, you're not just operating a ground station – you're becoming part of a movement that's reshaping the landscape of amateur satellite communication. First and foremost, VayuVani offers unrestricted access. No more roadblocks due to social media account requirements or IP blocking. Your ability to operate your station is entirely in your hands, giving you the freedom to explore and experiment without artificial limitations.

With VayuVani, you gain true ownership of your data. The information you collect belongs to you alone. You have the power to process, analyze, and share it as you see fit, without any third-party intermediaries. This level of data sovereignty is unprecedented in the world of amateur satellite communication.

The customization freedom VayuVani provides is unparalleled. You can tailor your ground station to your specific needs. Whether you're tracking weather satellites or experimenting with new signal processing techniques, VayuVani provides the flexibility to innovate and push the boundaries of what's possible. With its modular design, you are able to customize and make your own processing pipelines or decode the data you receive.

By operating an independent station, you're making a tangible contribution to science. The data you collect can aid in weather forecasting, climate research, and even space exploration. Your hobby becomes a valuable scientific endeavor, potentially contributing to breakthroughs in our understanding of our planet and beyond. The global networking aspect of VayuVani is equally exciting. You'll connect with a diverse, global community of space enthusiasts, engineers, and citizen scientists.

However, it's important to understand that joining VayuVani means taking an active role in your station's operation. Unlike other platforms where you might set up a station and let it run by Central Authority, VayuVani requires your active engagement. You'll be actively managing your station, making decisions about what to track, how to process data, and how to contribute to the community. This hands-on approach is both a responsibility and an opportunity – a chance to truly understand and shape your contribution to the world of satellite communication.

There's Already TinyGS for This

While TinyGS has done much to lower the entry barriers for LoRa-based satellite communication, VayuVani offers a fundamentally different approach. Where TinyGS relies on centralized control and external platforms, VayuVani puts you in the driver's seat.

With VayuVani, you're not just a node in someone else's network – you're on your own domain. Operate your station without the need for external servers or social media accounts. Your data, your rules. This level of autonomy means you can experiment, innovate, and push boundaries without waiting for approval or worrying about platform restrictions.

It's important to recognize that the field of amateur satellite communication is diverse and evolving. While TinyGS has made significant contributions, I strongly believe there's ample room for different approaches to address varying needs and preferences within the community. VayuVani represents one such approach, emphasizing user autonomy and offline capabilities. By offering an alternative, I aim to foster innovation and healthy competition in the field, potentially inspiring further advancements in amateur satellite communication technology. The goal is not to replace existing solutions, but to expand the options available to enthusiasts and researchers, thereby enriching the ecosystem as a whole.

In a world where internet outages can cripple operations, your VayuVani station keeps running, capturing valuable data regardless of your connectivity status. This resilience is crucial for consistent data collection and could be invaluable in emergency situations.

Key Features of VayuVani

I've designed VayuVani with a focus on autonomy, privacy, and flexibility:

• Full Control: You manage every aspect of your ground station independently.

• Enhanced Privacy: Operate without depending on external servers or platforms.

• Flexible Tuning: Choose between manual satellite selection or use VayuVani's auto-tune feature.

• User-Friendly Design: Accessible to both beginners and experienced operators.

• Modular Architecture: Comprising the Groundstation (GS), Groundstation Server (GSS), and Dashboard (D) for scalability and easy updates.

Future Directions

Looking ahead, I'm committed to continually improving VayuVani. Some key areas of focus include:

1. Expanding Compatibility: Ensuring VayuVani works with a wide range of hardware and software configurations.

2. Enhancing Auto-tuning: Developing more sophisticated algorithms for optimal satellite tracking.

3. Improving Data Analysis Tools: Building robust tools for packet decoding and analysis.

4. Strengthening Community Features: Creating more ways for users to share knowledge and collaborate.

5. Exploring Mesh Networking: Investigating possibilities for creating decentralized networks of ground stations.

Join the VayuVani Network

I'm inviting enthusiasts, tinkerers, and innovators to join the VayuVani community. Whether you're looking to set up your first ground station or you're an experienced operator seeking more control, there's a place for you in our network.

To get started:

1. Visit the project website at https://vayuvani.com for detailed information and setup guides.

2. Join our Discord community to connect with other station operators, share experiences, and get support.

3. Stay tuned for upcoming releases and community events.

Become VayuVani Station Operator

VayuVani is more than just a project – it's a movement towards democratized, independent satellite communication. By becoming a station operator, you're not just setting up a piece of technology; you're becoming part of a global network that's pushing the boundaries of what's possible in long-range communication.

Join me in giving voice to the signals in the air. Together, we can build a more connected, independent, and innovative future.

~FIN

On June 1 at 22:23 UTC, Chang'e 6 successfully landed on the far side of the Moon after a journey of nearly a month since its launch on May 3, 2024. The mission aims to collect and return samples from the Upper Mare Unit, which was formed during the Imbrian era approximately 3.85 to 3 billion years ago. If successful, these samples will be among the oldest ever collected from the Moon and potentially among the oldest collected from any celestial body.

Following the landing, the China National Space Administration (CNSA) released a video of the descent and landing sequence. Analysis of this footage indicates that Chang'e 6 approached its landing site from the east, eventually touching down at coordinates (-41.6384576, -153.9856638), as corroborated by Lunar Reconnaissance Orbiter (LRO) NAC images. Although the exact landing location is yet to be officially confirmed, it has been identified through visual feature matching.

Approximately two days after landing, which is imminent at the time of writing, Chang'e 6 will commence its ascent phase, aiming to return the samples collected by its drilling and sampling equipment.

I will continue to monitor and report on the progress of Chang'e 6, so stay tuned for more updates in my Lunar Exploration series.

~FIN

In my previous blog posts, I have demonstrated that Chandrayaan 2 operates beyond the commonly advertised 25cm resolution of images. The image capturing Vikram and Pragyan was at a 17cm resolution, and the SLIM was captured at an even finer resolution of 16cm. This level of detail is not widely known, as the 25cm resolution at 100km altitude is considered standard, making its capability to capture images at higher and finer resolutions rather obscure.

Over the past weeks, I've developed various techniques as part of my workflow to study all the published images captured by the Orbiter High-Resolution Camera (OHRC). Although all PDS4 (Planetary Data System version 4) data products come with a separate metadata file, you don't need to download the data to understand the conditions under which the image was taken. The PRADAN portal, though somewhat dated, allows users to view metadata without needing to download the data.

I've analyzed all the metadata of the data cataloged by OHRC that is available in the public domain. From this analysis, we can derive key insights into how OHRC is operated by ISRO and potentially glimpse its future capabilities.

But first, let’s understand what OHRC brings to the table and why it is ISRO's most important instrument for future missions –

The Moon's Highest Resolution Camera

The OHRC's optical system uses a Ritchey–Chrétien design, which is excellent at reducing image distortion due to its field-correcting optics (FCO). This design is also chosen for ShadowCam, which aims to image the PSRs in low-illumination conditions with different performance specifications compared to OHRC. The optical system of OHRC uses a 12,000 pixels Time Delay Integration (TDI) CCD detector. In contrast, ShadowCam uses a more sensitive TDI CCD designed to capture faint light in permanently shadowed regions.

The OHRC employs a primary mirror with a diameter of 300 mm and an effective focal length of 2046 mm, which allows it to achieve a narrow field of view (FOV) of ±0.86°. This setup enables OHRC to capture high-resolution images with a ground sampling distance (GSD) of 0.25 meters per pixel, providing a swath of 3 km at nadir at a nominal altitude of 100Km. This high resolution and wide swath enable OHRC to perform detailed surface characterisation and hazard detection with high precision [1].

OHRC’s optical configuration is designed to maintain high image quality. It includes measurements to ensure the sharpness and contrast of the images. The system keeps a modulation transfer function (MTF) of 24% at the highest spatial frequency it can detect, which helps in capturing images with fine details clearly.

What Makes OHRC Special and Suitable for Current and Future Lunar Missions

• High Spatial Resolution: At an optimal range of 90-95 km, the OHRC (Orbiter High-Resolution Camera) provides incredibly detailed images with a Ground Sampling Distance (GSD) of 24-26 cm per pixel. This high resolution is crucial for identifying small-scale surface features and potential hazards. Such detailed imaging is essential for mission planning, particularly when selecting safe landing sites and navigating the lunar surface.

• Ultra-High Resolution Stereo Imaging Capability: OHRC can capture multi-view stereo images within a single orbit through different spacecraft orientations, allowing the creation of digital elevation models (DEMs) with equally high spatial resolution. These models are vital for understanding lunar topography and identifying potential hazards such as slopes, boulders, and craters. The Space Applications Centre (SAC) uses a purpose-built indigenous software called OPTIMUS to generate these DEM files. The resulting DEM-Ortho pair offers approximately 28 cm horizontal and 100 cm vertical resolution [3], ensuring detailed topographical data useful for creating landing Hazard Maps [4].

• Adaptability to Illumination Conditions: OHRC's Time Delay Integration (TDI) Charge-Coupled Device (CCD) detector is optimized for low illumination conditions, such as those found during early lunar day cycles. This adaptability ensures that high-quality images can be captured even when the sun's elevation is low, maximising the operational time for the lander and rover instruments.

In comparison, ShadowCam has a slightly wider field of view (FOV) of approximately 2.86° and is designed to operate efficiently in extremely low light, with a spatial resolution of 1.7 meters per pixel from a similar altitude. ShadowCam's optical system includes enhanced baffling and a redesigned focal plane to reduce stray light, making it 200 times more sensitive than the Lunar Reconnaissance Orbiter Camera (LROC) Narrow Angle Camera (NAC). This enhanced sensitivity makes it five times more efficient in rejecting stray light. This specialized design, combined with its high sensitivity, makes ShadowCam highly effective for its primary mission of mapping and studying the lunar polar regions under low illumination conditions [2].

Both systems utilize their optical design to achieve their respective goals. OHRC focuses on high-resolution imaging for landing site characterization and terrain analysis, while ShadowCam specializes in imaging the dimly lit permanently shadowed regions to study lunar volatiles and polar environments. However, the specific features of OHRC, such as its high spatial resolution, stereo imaging capability, and adaptability to various illumination conditions, make it particularly well-suited for mission planning and safe landing site identification, which are critical for the success of lunar exploration missions.

Key Operational Insights

Since its inception in 2019, Chandrayaan 2 has made significant contributions to Indian lunar exploration. As of May 26, 2024, it has disseminated a total of 208 images, of which 104 are calibrated, amounting to approximately 229.73 GB of data, with each image averaging around 1.1 GB. It is my belief, however, that not all images captured by the OHRC have been released. Specifically, ISRO has denied access to the images that show the crash debris of the Vikram lander.

Navigating Operational Phases: Pushing the Limits to Define New Norms

The analysis of Chandrayaan 2's altitude data reveals distinct phases and significant trends throughout the mission. The initial stabilization phase (2019 - early 2020) shows consistent altitudes with minimal fluctuations, indicating a focus on establishing regular operations and calibrations. This is followed by the first adjustment phase (mid-2020 - early 2021), where significant altitude fluctuations suggest active orbit adjustments and maintenance activities. The operational stability phase (mid-2021 - late 2022) is characterized by stable altitudes and consistent image capture, reflecting routine and efficient mission operations.

In early 2023, the enhanced data collection phase begins, marked by increased imaging activity and moderate altitude variations, indicating an intensified focus on data acquisition. Early 2024 transitions into the boundary-pushing and adjustment phase, with significant variations in both minimum and maximum altitudes, suggesting extensive operational adjustments and efforts to maximize data collection capabilities. Throughout these phases, the nominal altitude range (90-99 km) serves as a reference for optimal operations, providing a benchmark for evaluating altitude variations. The detailed visualization of these phases highlights ISRO's strategic adjustments to optimize imaging capabilities and supports robust data acquisition for the Chandrayaan 2 mission.

It is noteworthy that ISRO’s SAC is actively recalibrating images from the initial Stabilization phase of the mission. For instance, an image from early September 2019 underwent calibration years later, in 2022 (ch2_ohr_nrp_20190906T1246532096_d_img_d18).

Shift in Focus: Chandrayaan 2 Expands Lunar Studies to the Polar Regions in Preparation for LUPEX

The mission's focus on the equatorial region of the Moon suggests a concentrated effort to study this area. However, the recent imaging from January to April 2024, efforts to identify potential landing sites for the LUPEX mission have already begun, leading to a spike in studying the polar region. Specifically, there were 46 observations made near the poles, with latitudes closer to 1° to the South Pole, under various illumination conditions where solar incidences were as low as 87°.

Evolution of Imaging Stations in the Chandrayaan 2 Mission

Most images are processed at the ISSDC Bangalore (D18) station. Throughout the mission, ISRO has utilized and transitioned among several imaging stations. Initially, operations were centered around SSDC Bangalore (D18) and ISSDC Bangalore (D32). More recently, stations such as ISSDC Bangalore (N18) and hw1 have been introduced. ISSDC Bangalore (N18) has seen increased activity starting in early 2023.

Notably, ISSDC Bangalore (D18) continues to be the primary station, with a peak in usage observed in April 2024. In contrast, hw1 was operational solely during 2021, likely serving as a temporary facility. This strategic evolution in infrastructure underscores ISRO's commitment to enhancing its imaging capabilities and supporting robust data acquisition and analysis for the Chandrayaan 2 mission.

Orbit Keeping & Maintenance: Seasonal and Yearly Analysis of Data Transfer Delays

The analysis of data transfer delays highlights significant variability in the time required to transmit data back to Earth. On average, delays are approximately 215 orbits, or about 18 days. However, examining the median delays offers a clearer picture of typical performance, revealing more consistent periods with delays under 1 day, indicative of efficient data handling processes.

Notable peaks, particularly observed in early 2022, suggest abnormal delays extending over to even several weeks! I hypothesise that these delays may be linked to maintenance activities, such as orbit-keeping events. Additionally, certain months, such as June and December, consistently exhibit higher delays, indicating potential seasonal operational challenges or external influences.

Normal delays generally range from a few hours to a few days, with median values under 1 day reflecting efficient data transfer. Abnormal delays, especially those spanning multiple days or aligning with the average delay of 18 days, underscore periods of operational disruptions. The heatmap visualizations effectively illustrate these patterns, highlighting both yearly and monthly trends.

The insights that are presented above are derived after extracting and analyzing all the metadata of the published OHRC images available at the time of writing this article. It is important to note that the scope of these insights falls within this specific frame of reference. The insights presented may or may not accurately reflect the true operations conducted by ISRO/SAC, as detailed information on their activities is currently unavailable. Unfortunately, ISRO has maintained a level of opacity regarding the specifics of their operations, leaving many aspects of their processes as a "black box." Through this article, I attempt to deduce some trends and patterns based on the available data, providing an analysis that may help in understanding the mission's operational dynamics and these are my interpretations based on the available information.

~FIN

[1] Chowdhury, Arup Roy, et al. “Orbiter High Resolution Camera onboard Chandrayaan-2 Orbiter.” Current Science, vol. 118, no. 4, 2020, pp. 560-565. Indian Academy of Sciences, doi:10.18520/cs/v118/i4/560-565 .

[2] Mahanti, Prasun, et al. “Preliminary Characterization of Secondary Illumination at Shackleton Crater Permanently Shadowed Region from ShadowCam Observations and Modeling.” Journal of Astronomical and Space Sciences, vol. 40, no. 4, 2023, pp. 131-148. Korean Space Science Society, doi:10.5140/JASS.2023.40.4.131 

[3] Amitabh, Ashutosh Gupta, K. Suresh, Ajay K. Prashar, Kannan V. Iyer, Abdullah Suhail A. Z., Shweta Verma, Baharul Islam B., Hemant K. Lalwani, and T. P. Srinivasan. “High Resolution DEM Generation from Chandrayaan-2 Orbiter High Resolution Camera Images.”

[4] Amitabh, K. Suresh, Ajay K. Prashar, and Abdullah Suhail A. Z. "Terrain Characterization of Potential Landing Sites for Chandrayaan-3 Lander using Orbiter High Resolution Camera (OHRC) Images."

The Lunar Geologic Timescale

The geological history of the Moon has been dominated by catastrophic impacts, separated by longer periods of gradual erosion and intermittent volcanic activity. Regolith accumulated on each deposit in direct proportion to its exposure duration and the prevailing impact conditions. Countless minor impacts continuously blurred surface textures, although subsurface geometries remained intact until disrupted by major impacts. Large impacts mixed ejecta with materials from various sources, including crater and basin units, regoliths, volcanic lavas, and subsurface intrusions.

Since the solidification of the crust, the lunar surface has consistently featured craters, ringed basins, and dark maria. However, the proportions of these features have evolved; the distribution of maria has continuously changed as new basins formed, filled with lava, and were overlain by ejecta from subsequent impacts. Volcanic activity persisted even as the rate of impacts declined, leading to more exposed basalt in later lunar history.

Pre-Nectarain Era and The South Pole Aitken Basin

The lunar and pre-Nectarian history of the Moon began around 4.55 Ga (Billion years), not long after the formation of the Moon itself. The exact process of accretion and the specifics of these early materials remained a subject of debate among researchers [3]. The pre-Nectarian period saw the formation of 30 identified basins, including notable ones like the Procellarum and South Pole-Aitken basins, which excavated material from about 40 percent of the Moon’s surface. The impact basins formed during this era are particularly significant as the South Pole-Aitken basin is recognized as the oldest.

The South Pole-Aitken Basin (SPA) is characterized by its elliptical shape, spanning dimensions of 2400x2050 KM, and centered at ~(53°S, 191°E). Analyses within the basin's best-fit ellipses indicate a north-south alignment in the distribution of iron, thorium, and regions of high topography, suggesting that an oblique impact may have influenced these distributions. The outer ellipse of the basin forms a discontinuous ring, prominently defined near the south pole and in the northeast, where the surrounding topography is elevated. However, this ring appears much weaker in the western regions [4].

The SPA basin's large, multi-ring, and elliptical structure, with a distinctive ~1.4 scaling along one axis, presents a unique geological framework. This makes it an invaluable natural laboratory for studying the generation and scaling of planetary rings, the dynamics of elliptical crater formation, and the development of massive basins more broadly [5].

Chang'e 6 Soil Sample Return Mission

The geological significance of obtaining samples from the South Pole-Aitken (SPA) Basin has become increasingly evident through recent advancements in lunar geological mapping. These efforts have been pivotal in studying the Moon's characteristics. Starting with the Chang'e-1 mission, the initial geological maps at a scale of 1:2.5 million [6] laid the groundwork for China's lunar exploration and were instrumental in the creation of a spatial database [7], marking a significant leap in Chinese planetary geological mapping.

In recent years, a comprehensive set of 1:2.5 million scale lunar geological maps was developed, encompassing the entire Moon. These maps detailed geological features, rock type distribution, and tectonic outlines [8-10], thereby enhancing the scientific community's ability to conduct detailed geological analyses. The Chang'e-6 mission, built on this foundation, is specifically designed to land in the lunar polar region and return samples [1].

Based on the study of the total area of ~890,000 km2 centered around the Apollo Basin, the site located in the southern part of the Apollo Basin within the SPA Basin (43°±2°S, 154°±4°W) is selected to support further research and sample return initiatives by the Chang'e-6 lunar probe.

The Apollo Basin is a focal point for current lunar geological research due to its exceptionally thin crust and prominent peak ring structures. These features suggest that the basin may expose some of the deepest lunar materials, potentially providing unique insights into the Moon's internal composition and geological history.

There remains significant debate regarding the composition of the lunar mantle in this region. There is a discrepancy between the in-situ observations from Chang'e 4 mission's Yutu-2 Rover which indicated the mantle's composition in the Von Kármán impact crater is primarily of olivine followed by low-calcium pyroxene [12], however, this contradicts the previous research in [11] which observed an abundance of low-calcium pyroxene in the same basin. This discrepancy raises questions about the heterogeneity or layered structure of the lunar mantle, which might vary significantly even within the same basin.

The Chang'e-6 mission is poised to play a crucial role in resolving these controversies. By landing in the Apollo Basin and collecting samples, particularly of low-calcium pyroxene rocks, Chang'e-6 could provide direct, on-site analyses of these materials. These samples would not only help determine the precise age and detailed chemical and mineralogical composition of the lunar mantle but also enhance our understanding of the geological processes that have shaped the Moon. Such data are vital for advancing our knowledge of lunar geology, particularly in terms of the composition and evolution of the lunar interior.

As of the drafting of this article, Chang'e 6 is en route to its designated sample collection site, though the exact location has not been disclosed to the public. I will continue my analyses pre and post-landing of Chang'e 6 in my Lunar Exploration series. To stay informed about the latest updates as soon as they are published, be sure to subscribe.

~FIN

[1] Liu, Liwei et al. "Regional Geological Characteristics and Evolution Analysis of the Pre-Selected Landing Area for the Chang'e-6 Probe." Frontiers of Earth Science, https://doi.org/10.13745/j.esf.sf.2023.12.29. Originally published in Chinese as "嫦娥六号探测器预选着陆区区域地质特征及演化分析"

[2] "Lunar Geologic Settings." Caltech Trailblazer, https://trailblazer.caltech.edu/lunarGeologicSettings.html.

[3] Wilhelms, Don. Geologic History of the Moon. U.S. Geological Survey Professional Paper 1348, 1987.

[4] Garrick-Bethell, Ian, and Maria T. Zuber. "Elliptical Structure of the Lunar South Pole-Aitken Basin." Icarus, vol. 204, no. 2, 2009, pp. 399-408. https://doi.org/10.1016/j.icarus.2009.05.032.

[5] Andrews-Hanna, J.C., Zuber, M.T., and Banerdt, W.B. "The Borealis Basin and the Origin of the Martian Crustal Dichotomy." Nature, vol. 453, 2008, pp. 1212–1215.

[6] Ding, Xiaozhong, Han Kunying, Han Tonglin, et al. "Compilation of the Lunar Rainbow Bay (LQ-4) Geological Map." Frontiers of Earth Science, vol. 19, no. 6, 2012, pp. 15-27.

[7] Wang, Liang, Ding Xiaozhong, Han Kunying, et al. "Compilation and Research of Lunar Digital Geological Map." Chinese Geology, vol. 42, no. 1, 2015, pp. 331-340.

[8] Ji, JZ, Guo, DJ, Liu, JZ, et al. "The 1:2,500,000-Scale Geologic Map of the Global Moon." Science Bulletin, vol. 67, no. 15, 2022, pp. 1544-1548.

[9] Chen, J, Ling, ZC, Liu, JZ, et al. "Digital and Global Lithologic Mapping of the Moon at a 1:2,500,000 Scale." Science Bulletin, vol. 67, no. 20, 2022, pp. 2050-2054.

[10] Lu, TQ, Zhu, K, Chen, SB, et al. "The 1:2,500,000-Scale Global Tectonic Map of the Moon." Science Bulletin, vol. 67, no. 19, 2022, pp. 1962-1966.

[11] Yamamoto, S., Nagaoka, H., Ohtake, M., et al. "Lunar Mantle Composition Based on Spectral and Geologic Analysis of Low-Ca Pyroxene- and Olivine-Rich Rocks Exposed on the Lunar Surface." Journal of Geophysical Research: Planets, vol. 128, no. 5, 2023.

[12] Li, CL., Liu, DW., Liu, B., et al. "Chang'E-4 Initial Spectroscopic Identification of Lunar Far-Side Mantle-Derived Materials." Nature, vol. 569, no. 7756, 2019, pp. 378-382.

On March 16, 2024, at approximately 04:57 UTC (10:27 IST), the Chandrayaan-2 Orbiter captured one of the highest-resolution images of SLIM. This image stands out as one of the highest-resolution captures from Chandrayaan-2, which typically produces images with a resolution between 20-30 cm per pixel. Remarkably, the resolution for SLIM was even finer, at around 16 cm per pixel—making it one of the highest-resolution images ever produced by the Orbiter's High-Resolution Camera (OHRC) - at least from the ones I have seen so far!

Ordinarily, Chandrayaan-2 operates at an altitude of 100 km, such as when it imaged the Vikram Lander from Chandrayaan-3. However, for this specific capture of SLIM, Chandrayaan-2 descended to a lower altitude of 63.7 km, enabling the unprecedented clarity of the image.

The left-hand image, captured by the Chandrayaan-2 orbiter at an altitude of 104 kilometers and a resolution of 26 centimeters, lacks accompanying metadata regarding solar azimuth and incidence angles. However, the orientation of the minimalistic shadows suggests acquisition during the lunar zenith when the solar longitude was westerly. In stark contrast, the imagery on the right—captured post-landing—demonstrates substantial enhancements.

The latest imagery from March 16th boasts an increased resolution of 10 centimeters per pixel, significantly refining the visual acuity of lunar surface topography. This resolution enhancement facilitates a more precise delineation of crater morphology and adjacent regolith features, which are vividly more discernible in the post-landing frame.

Moreover, this post-landing capture likely occurred during the initial lunar morning hours, approximately at sunrise. The solar azimuth is noted at 88 degrees, with a remarkably shallow solar incidence of around 6 degrees, positioning the sun "just" above the horizon. This geometry results in the elongation of shadows cast by lunar surface features, further accentuating the topographical details in the image.

Surviving the harsh Lunar nights

SLIM, the compact exploration lander of the Japan Aerospace Exploration Agency (JAXA) has already successfully demonstrated precise landing capabilities. It had been reactivated the second time, miraculously survived its second night, and now managed to survive its third Lunar night. SLIM has already fulfilled its FULL criteria and continues to achieve additional 'extra' goals, further extending its mission life.

Despite this success, the lander keeps facing challenges to endure the harsh nights; specifically, its battery cells and temperature sensors exhibit signs of wear and tear. Although the Multi-Band Camera (MBC) remains functional, JAXA is uncertain if SLIM will resume operational activities after enduring its third lunar night.

Harsh Environment

While a more scientific analysis of the contributing factors for the operational status of SLIM beyond its intended design specification is yet to be published, an underlining supposition could be made on its favorable equatorial landing site.

The average temperature in the equatorial region is typically around 400K(126°C), while the nighttime temperature can drop to approximately 95K (-178°C). In contrast, the average year-long temperature in the polar regions is about 98K (-175°C), not accounting for the permanently shadowed regions (PSRs). This significant temperature variation likely contributed to the successful reactivation of the ill-fated lander after each lunar night, occurring three times as of the date of this article. This capability, a noteworthy advantage, was unfortunately not available for Chandrayaan-3's Vikram lander, which now serves as India's permanent lunar ambassador.

A Brief look back at SLIM's landing

SLIM, the "Smart Lander for Investigating Moon" from JAXA, opted for a notably longer and somewhat unconventional trajectory to the Moon, taking approximately 19 weeks from launch to landing. This extended journey ranks it among the longest missions to the Moon. However, this was a deliberate choice, in line with its designated mission objectives. A key goal of SLIM is to enable more frequent lunar and planetary explorations by planning and designing cost-effective missions that utilize lightweight probes, capitalizing on Moon-Earth dynamics.

SLIM lander trejectory simulation prepared by Tony Dunn.

In the days leading up to its final and successful landing, JAXA shared detailed updates on SLIM’s descent toward the Moon's far side, including several releases of trajectory information and images captured during this descent phase.

The Far Moon Descent Maneuver (FDM) involved detailed telemetry, with 3D representations of SLIM’s orientation corresponding to specific moments in time. These visualizations provided key insights: the left view illustrated the lander’s attitude as seen from the sun, crucial for assessing the power generation status of the solar cells, while the right view depicted the attitude as seen from Earth, highlighting the status of antenna communications. These perspectives were instrumental in ensuring the lander's operational efficiency and communication reliability during its critical final approach.

Far Moon Descent Maneuver (ADM) of SLIM synced with the telemetry released by JAXA. Credits: JAXA/C.Tungathurthi

Here's the same FDM re-created using the actual trejectory information.

Towards Landing & Critical Failure

Despite an otherwise pristine launch and approach leading up to the landing, SLIM encountered a critical issue when it lost one of its engines just before landing due to an 'unknown' abnormality during its vertical descent phase, specifically just above an altitude of 50 meters. The exact cause of the engine's sudden failure is still under investigation. Despite this setback, the now-crippled lander managed to crash-land only 55 meters away from its intended landing site, demonstrating some resilience in its trajectory control systems under adverse conditions.

You can read the public press release here:

JAXA | Japan Aerospace Exploration Agency

Vision based pin-pointed landing

Despite a critical engine failure, SLIM successfully achieved a high-precision landing, fulfilling its primary objectives and now continues with its extended mission goals. Before initiating the powered descent phase, visual-based navigation was activated three times to refine the spacecraft's position. It was then employed twice more to correct its planned trajectory, and twice during the actual vertical descent, enabling the lander to touch down within 50 meters of the targeted location. In total, seven crucial corrections were made.

The precision of SLIM's landing was ensured by the spacecraft accurately self-locating within three strategically spaced craters. This meticulous positioning process involved continuous adjustments and real-time data processing to achieve the remarkable accuracy required for a successful mission outcome [2]

Here’s a detailed overview of the precise landing process:

1. Crater Identification: A robust method is employed to identify all the craters from images captured by the navigation camera. These images are analyzed to pinpoint crater features, essential for the subsequent steps.

2. Crater Selection: From the identified craters, a process of careful selection is undertaken to choose three craters that form a geometric 'triangle'. This selection is critical as it provides a foundational reference for precise localization.

3. Crater Database Matching: The triangle of craters is then matched against a pre-loaded crater database. This database contains detailed maps and positional data of known craters, which allows for an accurate comparison and verification.

4. Crater Pairing: For additional confirmation, adjacent craters are matched in a process known as "Crater Pairing." This step cross-verifies the initial matching by considering the spatial relationship between nearby craters.

5. Position Determination: Once the crater configurations are confirmed, the precise landing location is determined based on the located positions of the identified craters. This multi-step process ensures the accuracy of the lander’s final touchdown point.

These systematic and interlinked steps form a comprehensive approach to achieving a high-precision landing, critical for the success of the mission and the safety of the lander.

The entire landing sequence, from crater identification to position determination, has been meticulously optimized to enhance robustness under various challenging conditions. This optimization ensures the process can adapt to different illumination conditions and crater sizes, and it also involves filtering out craters that might introduce inaccuracies in the landing coordinates. The most crucial aspect of these enhancements is to make crater detection from camera images more efficient, especially considering the limited computational resources available on the lander while still maintaining high accuracy.

In my next post, I'll delve into the specific methods employed for crater detection, highlighting the techniques and technologies that enable precise analysis from navigation camera images. Following that, I will return to provide a more detailed walkthrough of the entire process, offering insights into how each step contributes to the successful and precise landing of the mission.

[1] https://www.diviner.ucla.edu/science

[2] Waragai, Yuka, et al (i-SAIRAS 2020). 2020.

[3] Takino, Tatsuya et al. “Crater Detection Method using Principal Component Analysis and its Evaluation.” Transactions of The Japan Society for Aeronautical and Space Sciences, Space Technology Japan 14 (2016):

As previously communicated in my announcement, I had the opportunity to deliver the inaugural presentation in the "Show & Talk" series. The video, featuring a collaboration with @Zetagravit on YouTube, is currently in post-production. In this update, I will share brief excerpts from each installment in the series - explaining a quick topic.

💡

Headphones 🎧 Due to recording gotchas - my audio wasn't recorded properly.

3D reconstruction of Sarabhai Crater using Chandrayaan-2 TMC2 Camera

A quick way to reconstruct Sarabhai Crater using Terrain Mapping Camera (TMC2) data of Chandrayaan-2 using QGIS

Post-landing image of Chandrayaan-3 featuring Vikram Lander

The Post-landing image of Chandrayaan-3 as captured by Chandrayaan-2 Orbital High-Resolution Camera (OHRC): the video shows a snippet of this image being post-processed in QGIS

Total lunar surface area mapped by ISRO with Chandrayaan-2.

All the area mapped by ISRO using Chandrayaan2 Orbiter - using Terrain Mapping Camera 2

PRADAN: Register and Browse through ISRO Data dissemination Portal

1×

here's the direct link to register

(more will follow ...)

Following my earlier announcements, I am excited to introduce the inaugural session of my series. Admittedly, there has been a delay due to a busy schedule, but I assure you that additional posts are coming – soon.

I plan to finalize and share more content in the next few days. Based on feedback from X, I'll focus on working with ISRO's data as the first topic, which has garnered significant interest. Please refer to the series description for more details.

For those interested in joining, the session will be accessible via Google Meet for interactive participation.

Additionally, I intend to stream a mirror of my session live on X and on YT for broader access but this will not be interactive and I dont expect it to have audio. Please follow Zetagravit for direct video stream.

This session is designed to be interactive and BYOM (Bring Your Own Machine), encouraging active participation and questions. I will try to answer as much as I can.

Before the session, I recommend visiting the ISSDC portal to register and download QGIS and needed plugin, ensuring you are prepared. Links and further instructions will be also provided during the session, but early preparation is encouraged.

I look forward to connecting with everyone soon.

~FIN

This is an excerpt from Strange Illuminations at the PSRs

The term "Permanently Shadowed Regions" (PSRs) refers to areas on the Moon that never receive direct sunlight due to the low obliquity of the Moon (1.54°). The PSRs at the South Pole are particularly intriguing because they are theorized to contain water ice and are shaded more than those at the North Pole, making them a key focus for research and exploration [2].

Water, a volatile substance on the lunar surface, is especially known to be present and is identified as the most stable compared to other naturally occurring volatiles that might have been released at any point. The quantity of water potentially lost since the lunar surface conditions evolved to the current state is very small.

As a result, the current levels of lunar ice are believed to closely reflect the total amount of water historically present on the lunar surface [4]. Naturally, these regions are of significant interest in planetary science and exploration. The believed water is thought to be trapped in the lunar soil, possibly deposited by impacts from space millions of years ago. This makes them not just important for scientific study but also potential sources of water for future lunar missions. The potential for extracting this ice signifies the importance of studying and exploring PSRs.

Cold Trapping

Cold-trapping is a process where certain regions can trap and freeze volatile substances like water vapor due to their extremely low temperature. Because of the lack of direct sunlight, these PSRs remain cold and have extremely low temperatures. Water sublimation (water to gas) is highly non-linear and slow at low temperatures. Hence, the probability of frozen water.

Temperature (C / K) Area (km²) -163 / 110 3.73 × 10^4 -162 / 111 3.79 × 10^4 -161 / 112 3.86 × 10^4 -160 / 113 3.92 × 10^4 -159 / 114 3.98 × 10^4 -158 / 115 4.04 × 10^4

Seasonal Winter Cold‐Trapping Area in South Polar Region for Threshold Temperatures [6]

Imaging and cataloging PSRs

Imaging PSRs at low illumination conditions is challenging, before the ShadowCam [14], the LRO team utilized the NAC to image PSRs. NAC images were captured using increased exposure times, and to enhance the SNR, the crosstrack-elongated pixels were binned to create a single pixel. Further calibration was performed using lronaccal and lronacecho routines. Ultimately, these images were orthorectified and stretched (2-98%) to create a final PSR NAC product.

All PSRs spanning areas greater than 10 km² have been cataloged in the PSR Atlas [5], each receiving a unique identifier. The atlas currently encompasses 324 PSRs across both the South and North Polar regions. Each PSR is assigned a unique ID; the ID begins with the first two characters indicating the polar region (NP for North Pole or SP for South Pole), followed by the centroid latitude, and then the centroid longitude. The values are delimited by underscores, with the latitude accurate to up to six digits, and the longitude to seven digits.

For eg: SP_871460_0840750

indicates a PSR in the South Pole region with the center 87.146 S, 84.075 E

[1] E. Cisneros, A.K. Boyd, H.M. Brown, A.A. Awumah, A.C. Martin, K.N. Paris, J. Leland, R.Z. Povilaitis, R. Hoppe, L.M. Davis, N.M. Estes, M.S. Robinson, and the LROC Team "Lunar Reconnaissance Orbiter Camera Permanently Shadowed Regions Atlas" July 6, 2018

[2] E. M. Shoemaker, M. S. Robinson, and E. M. Eliason, "The South Pole Region of the Moon as Seen by Clementine," Science, vol. 266, no. 5192, pp. 1851-1854, 1994, doi: 10.1126/science.266.5192.1851.

[3] Goldreich, Peter. "History of the Lunar Orbit". Reviews of Geophysics, Vol 4. November 1966.

[4] Watson, Kenneth M., Bruce C. Murray and Harrison S. Brown. “The behavior of volatiles on the lunar surface.” Journal of Geophysical Research 66 (1961): 3033-3045.

[5] Paul G. Lucey, "The Poles of the Moon",DOI: 10.2113/gselements.5.1.41

[6] Williams, J.‐P., Greenhagen, B. T., Paige, D. A., Schorghofer, N., Sefton‐Nash, E., Hayne, P. O., et al. (2019). "Seasonal polar temperatures on the Moon. Journal of Geophysical Research: Planets, 124, 2505–2521." doi:10.1029/2019JE006028

In the plan outlined for the series, I've identified several topics I'd like to discuss. This week, I intend to launch the series with my first talk, focusing on beginner topics.

Given that this is the inaugural session of the series, I have initiated a poll to determine which topics are of most interest to the audience. Your feedback is welcome; I will send out the details in the next few days. Please make sure to check your inbox for more information on how to participate in the session.

See you soon.

Make you sure you BYOM for the sessions that are interactive.

~FIN

Over the recent weeks, I have given considerable thought to the direction I wish to take, particularly as I invest an increasing amount of time into what I've lovingly termed 'unpaid' work. It has become increasingly apparent that my passion lies in delving deeper into current lunar missions and forthcoming space explorations, focusing on conducting detailed analyses and sharing my findings whether on X or other platforms.

In reflecting on recent lunar missions, it has become evident that both publicly and privately funded agencies have demonstrated a concerning level of opacity in their communication. This reluctance to openly share information, coupled with instances where data has been intentionally withheld, undermines the collaborative spirit essential for the advancement of space exploration. This trend stifles the scientific community's ability to build upon these missions and diminishes public trust and engagement in space science.

I believe what I do matters, so I'm doing what is best possible for me to do - not only as a learning opportunity for me but also to share insights that may not be readily apparent. Therefore, I'm moving what I thought to be just a 'personal blog' to a dedicated space to blog about the activities and my research and analysis around the Moon exploration and naturally, the missions above and beyond.

This move from my blog, blog.tgrthi.me to a new domain, moonandbeyond.blog is intended to more accurately reflect the main focus of my work and make the purpose of this space clearer to my readers.

~FIN

Over the last two decades, the lunar South Pole has emerged as a focal point for great scientific inquiry, driven by its potential to support future human missions and the possibility of establishing a permanent base on the Moon. This forward-thinking approach aims to lay the groundwork for more ambitious explorations such as Artemis.

Exploring the Moon isn't just about understanding its history; it's also crucial for planning our future in space. Many have expressed their desire for NASA to continue leading this effort. Frankly – it's evident that other spacefaring nations are rapidly advancing, narrowing the gap in exploration capabilities. I believe that future endeavors will necessitate a collective and collaborative approach, fostering a synergy that will benefit the advancement of space exploration.

Permanently Shadowed Regions 

The term "Permanently Shadowed Regions" (PSRs) refers to areas on the Moon that never receive direct sunlight due to the low obliquity of the Moon (1.54°). The PSRs at the South Pole are particularly intriguing because they are theorized to contain water ice and are shaded more than those at the North Pole, making them a key focus for research and exploration [8].

Water, a volatile substance on the lunar surface, is especially known to be present and is identified as the most stable compared to other naturally occurring volatiles that might have been released at any point. The quantity of water potentially lost since the lunar surface conditions evolved to the current state is very small.

As a result, the current levels of lunar ice are believed to closely reflect the total amount of water historically present on the lunar surface [7]. Naturally, these regions are of significant interest in planetary science and exploration. The believed water is thought to be trapped in the lunar soil, possibly deposited by impacts from space millions of years ago. This makes them not just important for scientific study but also potential sources of water for future lunar missions. The potential for extracting this ice signifies the importance of studying and exploring PSRs.

Cold Trapping

Cold-trapping is a process where certain regions can trap and freeze volatile substances like water vapor due to their extremely low temperature. Because of the lack of direct sunlight, these PSRs remain cold and have extremely low temperatures. Water sublimation (water to gas) is highly non-linear and slow at low temperatures. Hence, the probability of frozen water.

Temperature (C / K) Area (km²) -163 / 110 3.73 × 10^4 -162 / 111 3.79 × 10^4 -161 / 112 3.86 × 10^4 -160 / 113 3.92 × 10^4 -159 / 114 3.98 × 10^4 -158 / 115 4.04 × 10^4

Seasonal Winter Cold‐Trapping Area in South Polar Region for Threshold Temperatures [11]

Temperature Variations at PSR

The temperature at Permanently Shadowed Regions (PSRs) and the corresponding cold trapping depend on several factors, including topographical facets and the thermal conductivity of the regolith. One such factor is the phenomenon known as Secondary Illumination [1], I'll talk about it in the next sections.

From the Diviner observations [11], the probabilities of water trapping increase approximately 3 times during the winter. Moreover, the PSRs that cast double shadows due to multiple light scattering within the PSRs are observed to have lower temperatures and thereby increased chances of water deposits [12].

In the craters that exhibit double shadows, the heat sources are the thermal radiation due to the multiple light scattering that is the secondary form of "Illumination" inside the crater and is dependent on the

Future missions to the South Pole like LUPEX, VIPER are planned to do in-situ studies at the regions thought to have contain the water deposits.

Imaging and cataloging PSRs

It is now quite clear that imaging locations in low illumination conditions is challenging. Prior to the ShadowCam [14], the LRO team utilized the NAC to image PSRs. NAC images were captured using increased exposure times, and to enhance the SNR, the crosstrack-elongated pixels were binned to create a single pixel. Further calibration was performed using lronaccal and lronacecho routines. Ultimately, these images were orthorectified and stretched (2-98%) to create a final PSR NAC product.

All PSRs spanning areas greater than 10 km² have been cataloged in the PSR Atlas [5], each receiving a unique identifier. The atlas currently encompasses 324 PSRs across both the South and North Polar regions. Each PSR is assigned a unique ID; the ID begins with the first two characters indicating the polar region (NP for North Pole or SP for South Pole), followed by the centroid latitude, and then the centroid longitude. The values are delimited by underscores, with the latitude accurate to up to six digits, and the longitude to seven digits.

For eg: SP_871460_0840750

indicates a PSR in the South Pole region with the center 87.146 S, 84.075 E

The Physics of Secondary Illumination

In the preceding sections, I have explored the phenomenon of double shadows and their occurrence despite the absence of direct sunlight. This effect can be attributed to the topographical features within certain regions, leading to "secondary" illumination effects caused by light scattering off the crater's interior facets.

The above illustration explains the scattering of light rays, emphasizing the "yellow" areas directly illuminated by solar incidence. The "blue" areas represent regions illuminated by rays scattered from the "yellow" areas. Here, the illuminated parts of the crater, typically the upper regions of the crater wall, contribute as the "emitters," while the Permanently Shadowed Regions (PSR) act as the "receivers".

For clarity, the illustration simplifies this to a single bounce of light, though, in reality, multiple bounces are possible. An observer-independent concept, introduced in [1], has been applied to elucidate these illumination phenomena at Shackleton [2] and extended to investigate potential locations for the Artemis missions [3].

In the case of secondary irradiation (I_i,j ^1,2)—where the facets act as receivers—there is a strong correlation between the positions and orientations of the topographical facets and the Primary illumination (I_j,k ⁰) which serves as emitters.

I will not delve into the specifics of this model; the detailed explanation of the simulation model outlined above is provided in Sections II, and III in [1].

From the simulation results, a correlation between the simulated illuminated PSR and NAC images showed moderate agreement, with factors like stray light contamination and local photometric properties impacting the correlation negatively. Initial experimental results further validated the effectiveness of this methodology.

The approach for the computational estimation of secondary irradiance within lunar Permanently Shadowed Regions (PSRs), independent of an observer's position. While the method demonstrates a commendable capability in aligning simulated images with those obtained from LROC NAC long exposure captures—particularly in reflecting the impacts of seasonal insolation shifts and topographical nuances—an assessment suggests a refinement. Specifically, the methodology's robustness in varying lunar environmental conditions and its scalability for comprehensive lunar exploration missions could benefit from further exploration.

Nevertheless, the technique holds significant potential. It lays a foundational step towards enriching our pre-visit knowledge of lunar surfaces, particularly in PSRs, and potentially improving the quality and efficacy of lunar imaging.

In my next few posts, I'll talk about how these methods help us understand Shackleton and areas chosen as future landing missions.

[1] P. Mahanti, T. J. Thompson, M. S. Robinson, and D. C. Humm, "View Factor-Based Computation of Secondary Illumination Within Lunar Permanently Shadowed Regions," IEEE Geoscience and Remote Sensing Letters, vol. 19, 2022.

[2] P. Mahanti, M. S. Robinson, D. C. Humm, R. V. Wagner, N. M. Estes, and J.-P. Williams, "Preliminary Characterization of Secondary Illumination at Shackleton Crater Permanently Shadowed Region from ShadowCam Observations and Modeling," J. Astron. Space Sci., vol. 40, no. 4, pp. 131-148, 2023. DOI: 10.5140/JASS.2023.40.4.131.

[3] P. Mahanti, J.-P. Williams, M. S. Robinson, R. Wagner, E. Mazarico, M. Henriksen, H. Brown, and N. Kumari, "Dynamic Secondary Illumination in Permanent Shadows within Artemis III Candidate Landing Regions," The Planetary Science Journal, vol. 5, no. 3, 2024. DOI: 10.3847/PSJ/ad1b50.

[4] H. Bernhardt, M. S. Robinson, and A. K. Boyd, "Geomorphic map and science target identification on the Shackleton-de Gerlache ridge," Icarus, vol. 379, 2022, Art. no. 114963, doi: 10.1016/j.icarus.2022.114963.

[5] PSR Atlas http://lroc.sese.asu.edu/psr

[6] SER Data Portal https://data.ser.asu.edu/

[7] Watson, Kenneth M., Bruce C. Murray and Harrison S. Brown. “The behavior of volatiles on the lunar surface.” Journal of Geophysical Research 66 (1961): 3033-3045.

[8] E. M. Shoemaker, M. S. Robinson, and E. M. Eliason, "The South Pole Region of the Moon as Seen by Clementine," Science, vol. 266, no. 5192, pp. 1851-1854, 1994, doi: 10.1126/science.266.5192.1851.

[9] Goldreich, Peter. "History of the Lunar Orbit". Reviews of Geophysics, Vol 4. November 1966.

[10] Paul G. Lucey, "The Poles of the Moon",DOI: 10.2113/gselements.5.1.41

[11] Williams, J.‐P., Greenhagen, B. T., Paige, D. A., Schorghofer, N., Sefton‐Nash, E., Hayne, P. O., et al. (2019). "Seasonal polar temperatures on the Moon. Journal of Geophysical Research: Planets, 124, 2505–2521." doi:10.1029/2019JE006028

[12] Z. Yin, N. Liu, Y.-Q. Jin, "Simulation of the temperatures in the permanently shadowed region of the Moon's south pole and data validation," Icarus, vol. 411, 115917, 2024. doi:10.1016/j.icarus.2023.115917

[13] E. Cisneros, A.K. Boyd, H.M. Brown, A.A. Awumah, A.C. Martin, K.N. Paris, J. Leland, R.Z. Povilaitis, R. Hoppe, L.M. Davis, N.M. Estes, M.S. Robinson, and the LROC Team "Lunar Reconnaissance Orbiter Camera Permanently Shadowed Regions Atlas" July 6, 2018

[14] M. S. Robinson, P. Mahanti, L. M. Carter, B. W. Denevi, N. M. Estes, M. A. Ravine, E. J. Speyerer, and R. V. Wagner, "ShadowCam – Seeing in the Dark," in Proc. European Planetary Science Congress 2017, vol. 11, EPSC2017-506, 2017.

I've previously talked about the series and started documenting my tools and the workflow. I'm still working on a plan that I can properly schedule given my hectic work schedule and upcoming travel.

I have manged to think about the broad plan of the series. Here's list of topics I would like to talk about in no particular order.

Topic# Title Summary Interactive Session (BYOM) Approximate Time (mins) Link to Session 1 Open Science Data available for Lunar Exploration We will explore all the different lunar data and their formats that is available from different Space Agencies
including data from ISRO, NASA, CNSA, JAXA, and KARI. Yes but BYOM is not necessary 30-45 mins 2 Explore Lunar data: Work with OHRC/TMC2 data We will download OHRC and TMC2 data from ISSDC portal and start exploring it using QGIS.
I will explain the data format and structure of the PDS4 data shared by ISRO Yes and BYOM 60 mins 3 Explore Lunar data: Work with LRO data We will download LRO NAC and WAC files and We will use ISIS3 utils to calibrate raw EDR files and go through it step by step to create a Calibrated Dataset.
We will start exploring them using QGIS and use Qview
Yes and BYOM 60 mins 4 Introduction to SPICE Basics and Introduction to SPICE - an essential concept for understanding spacecraft positions in space and concepts around it NO 30-45 mins 5 Orbit Simulation for Chandrayaan2, SLIM Given we now know the fundamentals, we will download the ephemeris from JPL and recreate the simulation in orbitsimulator Yes and BYOM 30-45 mins 6 Advance Orbit Simulation for Chandrayaan2 and anything else Given we now know the fundamentals, we will download the SPICE and recreate the simulation in SPICE-enhanced Cosmographia Yes and BYOM 30-45 mins

In our interactive sessions, as implied, I encourage you to ask questions at any time. During the BYOM (Bring Your Own Machine) sessions, I'll assist you with downloading the necessary tools as needed.

I will update the session links after the conclusion of the sessions. These links will be shared in a separate blog post to the subscribers or registered users.

Please feel free to use the comment section below for more suggestions if you are interested any specific topic.

And If you're interested in arranging any of these sessions to be held in person, I warmly encourage you to contact me directly. I'm more than happy to discuss how we can make this happen.

A few days back, the LROC team finally released the 57C PDS Dataset and with it, we get a fresh perspective of the Luna 25 impact site, offering new insights into the mission's final moments. I will not go into the causative factors of the mishap, the official reason for Roscosmos is due to a faulty component in the onboard computer.

Here's the official statement for those interested:

Official Statement from Roscosmos (Translated to English)

"Luna-25": preliminary results of the work to determine the causes of abnormal station operation

On August 19, when issuing a corrective impulse to transfer the spacecraft from a circular circumlunar orbit to an elliptical pre-lunar orbit, the Luna-25 propulsion system operated for 127 seconds instead of the planned 84 seconds. As a result, the station entered an uncalculated unclosed orbit and collided with the lunar surface.

It was determined that the most probable cause of the accident was the abnormal functioning of the onboard control complex associated with the failure to turn on the accelerometer unit in the BIUS-L instrument (angular velocity measurement unit) due to the possible arrival in one data array of commands with different priorities of their execution by the instrument. In this case, the distribution of commands in data arrays has a random (probabilistic) character.

In this regard, the onboard control system received zero signals from the accelerometers of the BIUS-L device. This did not allow the corrective impulse to fix the moment of the required velocity and timely shutdown of the spacecraft propulsion system, as a result of which its shutdown occurred according to the time setpoint.

Recommendations on additional activities for subsequent lunar missions were formed.

Luna25 #MissionLuna25

Scott explained in detail about this and dissected the statment. There's also been plenty of explanations of it elsewhere, Anatoly Zak offers more insights leading upto the crash. He also gives an excellent history on its development

Immediately following the crash, the LROC Operations Team swiftly implemented a series of 4-hour sequence adjustments for the Lunar Reconnaissance Orbiter (LRO) to prioritize capturing the impact site on August 24, 2023. These efforts revealed that Luna-25 had impacted approximately 430 km away from its intended destination, conclusively ending the mission. Notably, this event occurred after the launch of Chandrayaan-3 but before its successful landing.

This image provides a detailed view of the crater resulting from the Luna 25 crash. Captured on September 21, 2023, this image comes a month after the Lunar Reconnaissance Orbiter (LRO) shared its initial images of the site. A closer examination highlights notable changes in albedo and the presence of crash ejecta, which are delineated in orange.

Further examination of the crater reveals that it spans approximately 13.5 meters in diameter, revealing a stark testament to the immense force of the impact.

Update 18.03:

Further processing of the dataset in Polar stereographic projection reduced the stretching issue - I've updated the images accordingly.

~FIN