Saturday, August 29, 2026

A strong case for C++ and Julia combination - my exploration continues - developing a PID controller using this approach using jluna...

 For a simple simulation or educational demonstration, we can do all of these in Julia. But in real-world applications, it's better to keep the hardware interfacing part written in C++ and the visualization part in Julia. This is a pretty common pattern (Python frontend + C++ backend, MATLAB + generated C, etc.), just with Julia instead of Python/MATLAB.

Below are some of the rational points when this tango of C++ and Julia is a good choice.

  • Real controller needs C++ strengths: If the “main controller” runs in a hard/soft real-time loop, on embedded hardware, interfaces with drivers/sensors/actuators (serial, CAN, ROS, etc.), or must meet strict latency/determinism guarantees, C++ (or C) is the conventional and safer choice. Julia’s GC, JIT compilation, and runtime make hard real-time harder (though there is recent work deploying Julia controllers on platforms like Raspberry Pi + PX4 or even microcontrollers).
  • Julia for the interactive layer: Julia excels at numerical work, control-theory tooling (ControlSystems.jl, DiscretePIDs.jl, ModelingToolkit, Dyad/JuliaSim control packages with PID autotuning), and modern interactive visualization (Makie/GLMakie with sliders, Observables, live plots of step responses, Bode/Nyquist, time series, etc.). Building a nice desktop or web-ish dashboard with live parameter sliders and plots is straightforward and productive in Julia.
  • Clean separation of concerns: Frontend (visualization + interactive tuning of
    K_p, K_i, K_d, etc.) stays in a high-level language good at maths and plotting; the performance-/hardware-critical loop stays in C++. Communication can be via sockets, shared memory, ZeroMQ, files, or (better) a thin C API + ccall / CxxWrap.jl / jluna-style interop

  • Finally, it may look like the following...



    Stage 0 : Verifying the basic configuration...




                        
                     

    Friday, August 28, 2026

    When My Son Inspired Me to explore a Bridge Between C++ and Julia...

    Here's the video of a very simple program in which the Julia runtime is embedded inside C++.




    Some programming projects begin with a problem.

    Some begin with curiosity.

    And some begin with a conversation between a father and his son.

    This one began with my son.

    My son has been exploring programming, graphics, simulation and the fascinating world of computers. As I watched him move from one technology to another—C++, Python, Java, graphics and simulation—I found myself revisiting areas of computer science that I had not touched seriously for years.

    And somehow, that journey brought me back to C++.

    But not just C++.

    It led me to Julia.

    And then came an interesting question:

    What if C++ and Julia could work together inside the same application?

    That question eventually led me to jluna.

    Why C++ and Julia?

    C++ and Julia come from rather different programming traditions.

    C++ is the language I naturally associate with systems programming, performance, memory control, large-scale simulation and real-time applications.

    Julia, on the other hand, feels almost purpose-built for scientific computing.

    It combines a high-level mathematical syntax with impressive numerical performance.

    For someone interested in physics simulation, control systems, computational science and graphics, the combination is rather attractive.

    Imagine having the core simulation or controller in C++, while using Julia for:

    • numerical experimentation

    • visualization

    • plotting

    • interactive parameter tuning

    • rapid prototyping

    • scientific analysis

    That immediately opens up some interesting possibilities.

    The idea of a bridge

    Calling C++ from Julia is already possible through several mechanisms.

    But I was particularly interested in the opposite direction:

    Embedding Julia inside a C++ application.

    The architecture I had in mind was something like this:

                     C++ Application
                           │
                  ┌────────┴────────┐
                  │                 │
            Simulation /        Julia Runtime
            Controller              │
                  │          ┌───────┴───────┐
                  │          │ Visualization │
                  │          │ Experimentation│
                  │          │ Data Analysis │
                  │          └───────────────┘
                  │
                  └────────── jluna ──────────┘
    

    This is where jluna became interesting.

    Rather than treating Julia as a completely separate program, jluna provides a C++ interface for interacting with an embedded Julia runtime.

    And suddenly, the idea of a C++ program calling Julia code didn't feel so exotic.

    My first jluna experiment

    I decided not to start with a complicated application.

    No physics engine.

    No PID controller.

    No graphics.

    Just a tiny experiment:

    Can a C++ program start Julia and execute Julia code?

    That simple question became the first milestone.

    I created a small C++/CMake project and started working through the mechanics of embedding Julia.

    There were several pieces to understand:

    • locating the Julia installation

    • configuring CMake

    • linking the C++ application

    • initializing the Julia runtime

    • evaluating Julia expressions

    • passing values between C++ and Julia

    The interesting part wasn't simply getting the first program to run.

    It was understanding where the boundary between the two languages actually lies.

    Crossing the language boundary

    Once you start thinking about C++ and Julia as two parts of the same application, a more interesting question appears:

    What should belong to C++, and what should belong to Julia?

    For example, consider a PID controller.

    The controller itself could live in C++:

    Sensor
       ↓
    C++ PID Controller
       ↓
    Actuator
    

    But during development, I might want Julia to provide:

                 Julia
                   │
           ┌───────┼────────┐
           ↓       ↓        ↓
         Plot     Slider   Analysis
           │       │        │
           └───────┼────────┘
                   ↓
                 C++
              PID Controller
    

    Julia could change Kp, Ki and Kd interactively.

    The C++ controller could continue doing the real work.

    Julia could plot the response in real time.

    Now the bridge becomes much more than a programming curiosity.

    It becomes an architecture for experimentation.

    The father-son effect

    There is something amusing about this journey.

    I started exploring C++ and Julia because my son was exploring programming and simulation.

    Instead of simply teaching him something, I found myself learning something new as well.

    That is one of the unexpected pleasures of being a parent.

    Sometimes we imagine that we are introducing our children to technology.

    But they quietly introduce us to new technology too.

    A question from a young programmer can send a father down a rabbit hole involving CMake, compilers, ABI compatibility, Julia's runtime, C++ templates and foreign-function interfaces.

    And suddenly it is midnight and you're reading documentation about jluna.

    Why this exploration matters to me

    I'm not approaching jluna because I need another language binding for a production application.

    I'm exploring it because it sits at an interesting intersection of several things I enjoy:

    C++ + numerical computing + simulation + visualization + experimentation.

    C++ gives me control and performance.

    Julia gives me an expressive scientific environment.

    And jluna provides the bridge.

    The more I explore this combination, the more interesting the possibilities become.

    Perhaps the final project will be a PID controller.

    Perhaps a physics simulation.

    Perhaps something involving graphics.

    Or perhaps it will simply remain another enjoyable rabbit hole in my never-ending journey through computer science.

    But that is perfectly fine.

    Because sometimes the best projects aren't the ones that solve a business problem.

    They are the ones that make you curious again.

    And this particular curiosity started with my son.

    **He was exploring programming.

    I followed him down the rabbit hole.

    And somewhere along the way, we discovered a bridge between C++ and Julia.**



    Monday, August 3, 2026

    From Eclipse CDT to Zed + clangd — The Exploratory Engineer in Me Is Still Alive...



    I recently started moving from Eclipse CDT to Zed + clangd for my C++ development.

    On the surface, it is just an IDE change.

    For me, it is something more.

    Eclipse CDT has been a trusted companion for years. Projects, indexing, debugging, builds, refactoring—everything became familiar. And that familiarity is comfortable.

    But there is a danger in becoming too comfortable with the tools. Development becomes routine. We loose the power of curiosity.

    And then...

    Things that had become invisible are interesting again.

    Look at the image, which is clangd's compile_commands.json.

    clangd needs to know this information.

    Which compiler?

    Which C++ standard?

    Which include directories?

    Which preprocessor definitions?

    Which compilation flags?

    Once I started looking at it this way, clangd stopped feeling like some mysterious IDE feature.

    It became what it really is:

    a tool that needs an accurate model of how the compiler sees the source code.

    That shift in perspective makes troubleshooting much easier.

    How does clangd understand my project?
    What exactly does CMake generate?
    How does the debugger interact with my program?
    How much of an IDE do I actually need?

    These are not merely editor questions. They are engineering questions.

    And perhaps that is what I enjoy most.


    As engineers gain experience, there is a risk of becoming operators of familiar systems rather than explorers of new ones.

    I don't want that.

    The move from Eclipse to Zed is therefore not really about:

    Eclipse → Zed + clangd




    It is about:

    Routine → Exploration

    Familiarity → Curiosity

    "This is how I always do it" → "What happens if I try this?"

    Why This Experiment Is Interesting to Me

    I have always enjoyed understanding what happens underneath the abstraction.

    That is probably why I keep moving between areas such as:

    • C++
    • Java
    • Python
    • Linux
    • OpenGL
    • CUDA
    • OpenFOAM
    • ParaView
    • Julia
    • Blender
    • numerical simulation
    • computer graphics
    • design patterns

    There is a common thread running through all of them.

    I don't just want to use the software.

    I want to understand how the machinery works.

    Moving from Eclipse CDT to Zed + clangd is another small expression of the same instinct.

    The editor itself becomes less important.

    The interesting part is understanding the ecosystem around it.



    The tools will keep changing—C++, compilers, build systems, editors, AI, GPUs, simulation frameworks.

    The important thing is to keep experimenting.

    Because after years of programming, discovering a new tool is nice.

    But discovering that the explorative engineer inside me is still alive—and thriving is much better.

    Friday, July 31, 2026

    NavIC Mandate: Why India’s Navigation System Could Become the Backbone of Bharat’s Digital Sovereignty...

    For decades, whenever an Indian smartphone displayed its location, whenever an aircraft calculated its position, whenever a vehicle tracked its route, or whenever a digital system needed precise time, India largely depended on technologies built around foreign satellite-navigation constellations.

    GPS from the United States.
    Galileo from Europe.
    GLONASS from Russia.
    BeiDou from China.

    They are excellent systems. But there is a fundamental strategic question:

    Can a sovereign digital economy afford to depend completely on somebody else's space-based positioning, navigation and timing infrastructure?

    That is the deeper significance of NavIC — Navigation with Indian Constellation.

    A mandate requiring appropriate GNSS-enabled hardware to support NavIC, particularly its modern multi-frequency signals, would therefore be much more than another technical specification.

    It would be a step towards Bharat's digital sovereignty.


    1. NavIC is not simply India's "GPS"

    NavIC was conceived as an independent regional satellite-navigation system providing Position, Navigation and Timing — PNT — services over India and a region extending roughly 1,500 km beyond the Indian landmass.

    Its civilian Standard Positioning Service and strategic Restricted Service are designed around India's own navigation infrastructure.

    The present NavIC architecture uses:

    • L5 — 1176.45 MHz
    • S-band — 2492.028 MHz

    The newer generation introduces:

    • L1 — 1575.42 MHz

    The L1 signal is particularly important because it makes NavIC much more compatible with the frequencies already used by mass-market GNSS receivers. ISRO says forthcoming NavIC satellites are designed to broadcast L1, L5 and S-band signals.

    That changes the economics of NavIC adoption.

    Instead of building a special receiver exclusively for NavIC, manufacturers can increasingly integrate NavIC into the same GNSS architecture used for GPS, Galileo, BeiDou and other constellations.


    2. Why a hardware mandate matters

    Suppose India says:

    If a device contains satellite-navigation capability, it must support NavIC.

    That single policy decision can change the entire semiconductor ecosystem.

    Today, a chip designer can ask:

    "Why should I spend silicon area, engineering time and certification money supporting NavIC?"

    A mandate changes the question to:

    "How do I implement NavIC efficiently?"

    That creates demand.

    Demand creates chipsets.

    Chipsets create module manufacturers.

    Modules create device compatibility.

    Device compatibility creates applications.

    Applications create an ecosystem.

    And suddenly NavIC stops being merely a government space programme and becomes infrastructure for the digital economy.

    This is precisely how technology sovereignty develops.


    3. The real strategic asset is not the satellite — it is PNT

    There is an important concept hiding behind NavIC:

    Position + Navigation + Timing

    Most people think of GNSS as a location service.

    But the T in PNT — Timing — may be even more strategically important.

    Modern infrastructure depends on extremely accurate time synchronization.

    Financial networks.

    Telecom networks.

    Electric grids.

    Data centres.

    5G/6G networks.

    Power-grid protection.

    Transportation.

    Banking transaction ordering.

    Scientific instruments.

    Military systems.

    Satellite communications.

    Autonomous vehicles.

    All depend, directly or indirectly, on accurate timing.

    Therefore, a sovereign navigation constellation is also a national timing infrastructure.

    This is why atomic clocks are so important.


    4. Why atomic clocks matter so much

    A GNSS satellite continuously broadcasts a signal containing precise timing information.

    The receiver measures how long the signal took to arrive.

    If the satellite's clock is wrong by even a tiny amount, the calculated distance becomes wrong.

    And when distances from several satellites are combined, those errors propagate into the calculated position.

    In simple terms:

    Satellite clock → signal timing → range measurement → position

    So the atomic clock aboard a navigation satellite isn't just another component.

    It is one of the foundations of the navigation system.

    That is why the recent NavIC clock problem deserves attention.


    5. The 2026 clock problem: what actually happened?

    On 13 March 2026, the procured onboard atomic clock of IRNSS-1F stopped functioning.

    The satellite had already completed its 10-year design mission life on 10 March 2026. ISRO stated that although the clock had stopped, the satellite would continue to provide one-way broadcast messaging services.

    This was significant because IRNSS-1F was one of the remaining satellites contributing to NavIC's navigation capability.

    The failure exposed an uncomfortable strategic vulnerability:

    India had built an independent navigation constellation, but parts of the most critical timing technology were still externally procured.

    That is precisely the kind of dependency that digital sovereignty is supposed to eliminate.


    6. But there is an important misconception about NVS-02

    The story is sometimes simplified as:

    "Foreign atomic clocks failed, causing NVS-02 to fail."

    That is not what ISRO's investigation found.

    NVS-02 was launched on 29 January 2025. It successfully reached its intended transfer orbit, but its orbit-raising manoeuvre failed.

    ISRO's Apex Committee concluded that the most likely cause was the drive signal not reaching the pyro valve of the oxidizer line, with disengagement of contacts in the connector identified as the likely cause.

    ISRO subsequently implemented corrective measures on future missions.

    And there is an encouraging detail that deserves much more attention:

    ISRO's 2025–26 Annual Report says the indigenous atomic clock on NVS-02 was thoroughly evaluated and was exceeding specification.

    That is very different from saying India's indigenous clock technology has failed.

    In fact, the clock story may ultimately become one of India's most important successes.


    7. India has already crossed the most important technological barrier

    NVS-01, launched in May 2023, carried an indigenous atomic clock for the first time.

    NVS-02 also contains indigenous atomic-clock technology.

    ISRO's own assessment says the indigenous clock on NVS-02 is exceeding specification.

    That means the strategic problem is no longer simply:

    "Can India build an atomic clock?"

    India has demonstrated that it can.

    The challenge is now much more industrial:

    Can India manufacture these clocks reliably, qualify them for long-duration space operation, build enough of them, and integrate them into a rapidly expanding constellation?

    That is a very different problem.

    And it is a solvable one.


    8. The bigger bottleneck is the constellation

    There is another uncomfortable reality.

    A navigation system needs enough healthy satellites simultaneously available to provide robust positioning.

    The loss of an individual satellite therefore matters much more in a relatively small regional constellation than it would in a huge global constellation.

    The failure of IRNSS-1F reduced the available navigation architecture at an unfortunate time.

    At the same time, the second-generation replacement programme has been progressing more slowly than originally hoped.

    NVS-02's orbit-raising problem was one setback.

    The remaining NVS satellites are therefore strategically important.

    NavIC needs not merely good satellites.

    It needs constellation redundancy.


    9. The second bottleneck: indigenous clocks must become an industrial product

    Developing one excellent prototype is not the same as manufacturing hundreds of flight-qualified units.

    The clock must survive:

    • launch vibration
    • acoustic loads
    • vacuum
    • thermal cycling
    • radiation
    • long-duration operation
    • power fluctuations
    • ageing
    • repeated frequency-control operations

    And it must continue operating reliably for years.

    This is the difference between:

    laboratory technology

    and

    space-qualified industrial technology.

    India is moving from the first category toward the second.


    10. The third bottleneck: NavIC receiver silicon

    There is little point in having a sovereign satellite constellation if the majority of the world's receivers cannot hear it.

    This is why the receiver-chip ecosystem matters enormously.

    ISRO has already worked with Qualcomm to enable NavIC L1 support on mobile, automotive and IoT platforms.

    ISRO's 2023–24 annual report also recorded more than 50 NavIC-capable mobile handsets and noted that wearables, trackers and IoT devices traditionally use small, low-power single-frequency GNSS chips. The introduction of L1 is specifically intended to make NavIC easier to integrate into these consumer devices.

    The next step is therefore obvious:

    NavIC must become a default capability of GNSS silicon manufactured for the Indian market.


    11. And India is building the silicon

    One of the most interesting developments is happening away from the satellites.

    ISRO's 2025–26 Annual Report reports an indigenous 28-nm NavIC + GNSS digital baseband ASIC.

    It supports:

    • 100 tracking channels
    • NavIC and other GNSS open-service signals
    • a dual-core processor
    • an on-chip PLL
    • anti-jamming capabilities

    This is precisely the kind of technology that turns NavIC from a space project into a semiconductor ecosystem.

    The strategic chain begins to look like this:

    Indian satellite

    Indian atomic clock

    Indian navigation signal

    Indian GNSS baseband

    Indian receiver/module

    Indian smartphone/vehicle/drone/IoT device

    Indian PNT ecosystem

    That is digital sovereignty.


    12. Why dual-frequency NavIC is particularly important

    A modern receiver can exploit measurements on multiple frequencies.

    The ionosphere affects different frequencies differently.

    By observing multiple frequencies, the receiver can estimate and compensate for a significant part of this error.

    That improves positioning robustness and accuracy.

    But there is another strategic advantage:

    Once Indian devices routinely support multiple NavIC frequencies, NavIC becomes deeply embedded in the hardware ecosystem.

    It is no longer an optional checkbox.

    It becomes part of the silicon architecture.

    That makes it much harder for the ecosystem to quietly abandon NavIC later.


    13. The mandate is therefore bigger than navigation

    Imagine an Indian automobile five years from now.

    Its navigation computer receives:

    NavIC + GPS + Galileo + BeiDou + GLONASS

    The receiver doesn't have to reject foreign constellations.

    Quite the opposite.

    India should encourage multi-constellation interoperability.

    But NavIC should be guaranteed as one of the available sources.

    This is the right philosophy:

    Strategic autonomy does not mean technological isolation.

    It means having your own independent option.


    14. Think of NavIC as India's digital "sovereign layer"

    India has already built several sovereign digital infrastructures.

    UPI created an Indian payment rail.

    Aadhaar created a digital identity infrastructure.

    India Stack created reusable digital public infrastructure.

    Now imagine NavIC becoming the sovereign PNT layer underneath them.

    Payments need accurate time.

    Telecom needs synchronization.

    Logistics needs positioning.

    Agriculture needs precision positioning.

    Drones need navigation.

    Autonomous vehicles need PNT.

    Emergency systems need location.

    Defence systems need independent navigation.

    Disaster-warning systems can use NavIC's messaging capability; ISRO notes that NavIC messaging has already been integrated into India's Common Alert Protocol and used through the Sachet system.

    NavIC therefore has the potential to become another foundational layer of India's digital infrastructure.


    15. So how long will ISRO take to "fix the imported-clock problem"?

    Here we need to be careful.

    There is no credible public ISRO timetable saying "the imported-clock problem will be completely solved by X months."

    And it would be misleading to invent one.

    The evidence available today points to a more nuanced answer.

    India has already demonstrated indigenous atomic clocks in the NVS programme. ISRO says the indigenous clock on NVS-02 is exceeding specification.

    The real remaining challenge is constellation replacement + production + qualification + reliability + launch cadence.

    Therefore, I would think about the timeline in three stages:

    Stage 1 — Technology demonstrated

    Already achieved.

    The indigenous clock has flown and ISRO reports performance exceeding specification.

    Stage 2 — Operational confidence

    The next few NVS missions are crucial.

    Repeated successful operation in orbit will establish confidence that the indigenous clock is not merely a successful prototype but a dependable production technology.

    Stage 3 — Full constellation resilience

    This will take longer than simply developing the clock.

    Several satellites must be launched, commissioned and maintained with sufficient redundancy.

    So the sensible estimate is:

    Clock technology: essentially already demonstrated.

    Reliable production and qualification: a multi-year industrialisation task.

    A fully resilient NavIC constellation: likely a multi-year programme rather than something that can be repaired overnight.

    That distinction is crucial.


    16. The good news: the bottleneck is no longer purely technological

    This is perhaps the most encouraging conclusion.

    India isn't standing at zero.

    ISRO already has:

    ✓ NavIC satellites
    ✓ indigenous navigation signals
    ✓ L1/L5/S capability
    ✓ indigenous atomic clocks
    ✓ indigenous GNSS receiver technology
    ✓ indigenous 28-nm GNSS baseband development
    ✓ NavIC-enabled smartphones
    ✓ automotive and IoT integration
    ✓ navigation-message authentication technology
    ✓ an operational ground segment

    ISRO's latest annual report says the NavIC ground segment is fully functional and that navigation-message authentication has been developed and tested.

    The challenge now is scale, reliability and redundancy.

    That is an industrial problem.

    And industrial problems can be solved by building.


    17. What should Bharat do next?

    If NavIC is to become a genuine pillar of digital sovereignty, India should pursue five parallel tracks.

    1. Make NavIC mandatory in appropriate GNSS-enabled devices

    Not every electronic device.

    But smartphones, vehicles, navigation modules, trackers, drones, strategic equipment and other relevant GNSS-enabled products should progressively support NavIC.

    2. Make multi-frequency capability the target

    L1 + L5 support should become increasingly common rather than treating NavIC as a single-frequency add-on.

    3. Build an Indian GNSS-chip industry

    The real sovereign asset is not only the satellite.

    It is the receiver silicon.

    4. Make indigenous atomic clocks a mass-production capability

    One clock that works is an achievement.

    A reliable supply of hundreds of flight-qualified clocks is sovereignty.

    5. Build constellation redundancy

    A sovereign system must not be brought close to a minimum-operational threshold by the loss of one ageing satellite.

    The system needs reserve capacity.


    18. The real lesson from the clock failures

    It is tempting to interpret the recent NavIC problems as evidence that the project has failed.

    I would interpret them differently.

    They reveal exactly why sovereignty matters.

    If an imported component fails after a decade in orbit, India cannot simply send an engineer to replace it.

    The satellite is 36,000 km away.

    The lesson is therefore not:

    "India should never use foreign technology."

    The better lesson is:

    "India should never remain permanently dependent on foreign technology for a critical strategic capability."

    Use foreign technology while necessary.

    Learn from it.

    Build indigenous alternatives.

    Fly them.

    Qualify them.

    Mass-produce them.

    And eventually make the foreign component optional.

    That is how technological sovereignty is created.


    19. From Atmanirbhar Bharat to PNT sovereignty

    NavIC began as a response to a strategic reality:

    satellite navigation is too important to leave entirely to somebody else.

    Today, that argument is even stronger.

    The digital economy has become dependent on invisible infrastructure.

    We see maps.

    We see timestamps.

    We see automated vehicles.

    We see digital transactions.

    We see telecom networks.

    But underneath them are billions of precise measurements of where and when.

    That is PNT.

    And whoever controls reliable PNT possesses an important layer of technological sovereignty.


    20. The destination

    The ultimate goal should not be:

    "Replace GPS with NavIC."

    That would be the wrong objective.

    The goal should be:

    "Make NavIC unavoidable in India's digital infrastructure while remaining interoperable with the world's GNSS systems."

    A future Indian receiver should happily use:

    NavIC + GPS + Galileo + BeiDou + GLONASS

    But if every Indian GNSS receiver also has NavIC capability, India possesses something far more valuable than another navigation constellation.

    It possesses an independent fallback and strategic PNT layer.

    And if the satellites, atomic clocks, receiver chips, operating software and authentication infrastructure are all increasingly Indian, the dependency chain becomes progressively shorter.

    That is the real meaning of a NavIC hardware mandate.

    It is not merely about finding your location on Google Maps.

    It is about ensuring that, when India needs to know where it is and when it is, it does not have to ask anybody else.

    **NavIC is therefore not just a navigation system.

    It is a building block of Bharat's digital sovereignty.**


    Thursday, July 30, 2026

    When France Said No: How India Turned GaN Technology Denial into a Semiconductor Opportunity - joining the dots...



    There is a fascinating story unfolding in India's semiconductor journey—one that begins not in a commercial semiconductor fab, but around the strategic technology negotiations associated with the Rafale era.

    At the centre of the story is a deceptively small piece of semiconductor technology:

    Gallium Nitride — GaN.

    Today, GaN is one of the most strategically important semiconductor technologies for high-frequency and high-power electronics. It can be used in radar, electronic warfare, satellite communications, telecom infrastructure and advanced power electronics.

    And India's journey towards mastering it illustrates an important principle of technological sovereignty:

    When a critical technology cannot be bought, the alternative is to learn how to build it.

    The first dot: technology denial

    During the Rafale negotiations, reports have circulated that India sought access to advanced GaN semiconductor technology associated with French defence electronics, but that the sensitive technology itself was not transferred.

    The important distinction is between buying a finished component and acquiring the know-how to manufacture the underlying technology.

    The former creates a customer.

    The latter creates technological capability.

    Public reporting on the Rafale-era episode is not accompanied by a publicly available French government document establishing every detail of the alleged request and refusal, so the claim should be treated cautiously. But the broader technology-denial narrative has been widely reported.

    And then something important happened.

    India did not remain dependent on imported GaN technology.


    The second dot: DRDO starts building the capability

    India's Defence Research and Development Organisation pursued indigenous GaN technology through its semiconductor research ecosystem.

    The Solid State Physics Laboratory (SSPL) and Gallium Arsenide Enabling Technology Centre (GAETEC) worked on GaN semiconductor devices and MMICs.

    By March 2023, GaN MMICs fabricated through this ecosystem had successfully undergone functionality testing. The development was significant because GaN MMICs are particularly relevant to high-frequency defence applications.

    By 2024, DRDO had also announced indigenous work involving GaN HEMTs, alongside development of 4-inch silicon-carbide wafers. The reported GaN devices reached power levels up to 150 W.

    This is much more significant than merely producing "a chip".

    A modern radar or electronic-warfare system requires an entire RF semiconductor technology chain:

    materials → epitaxy → transistor → MMIC → RF module → antenna system → radar/EW platform

    Controlling more of that chain means controlling more of the technology.


    But DRDO is only half the story

    Here is where the story gets really interesting.

    A defence laboratory can demonstrate a technology.

    But a nation does not achieve semiconductor sovereignty simply by producing a successful laboratory prototype.

    The technology has to escape the laboratory.

    It needs:

    research → manufacturing → testing → qualification → products → customers → scale

    And that brings us to IISc and AGNIT Semiconductors.


    The third dot: IISc's long GaN journey

    Long before India's current semiconductor boom, researchers at the Indian Institute of Science (IISc), Bengaluru, had been working on GaN technology.

    AGNIT says its technology base comes from more than 17 years of GaN research at IISc. The company emerged as an IISc spin-off in 2021. By 2022 it had sold its first wafers and developed RF prototypes, followed by commercial RF devices in 2023.

    This is an extremely important distinction.

    AGNIT isn't simply an Indian company assembling imported GaN components.

    It describes itself as a fab-lite GaN semiconductor company, developing GaN wafers, components and modules for telecommunications, defence and strategic applications.

    In other words:

    Indian research → Indian IP → Indian startup → Indian GaN products.

    That is the missing bridge between laboratory research and industrial capability.


    The fourth dot: AGNIT starts building the industrial layer

    The development becomes even more interesting in 2026.

    AGNIT has established a ₹3-crore GaN testing and qualification laboratory at IISc Bengaluru.

    The facility includes environmental testing capability from −60°C to +125°C, RF measurement equipment, connectorised load-pull testing and automated PCB assembly capability.

    Why is testing so important?

    Because making a transistor is not the same thing as making a reliable semiconductor product.

    A defence or telecom customer needs to know:

    • Does the device work across temperature?
    • How stable is it?
    • How much RF power can it deliver?
    • What happens under stress?
    • How does manufacturing variation affect performance?
    • Can thousands of devices meet the same specification?

    Qualification infrastructure is therefore part of semiconductor sovereignty.

    AGNIT is effectively building another piece of that ecosystem.


    Now connect the dots

    Look at the sequence:

    1. Strategic technology becomes inaccessible

    GaN technology is considered strategically sensitive.

    2. India develops indigenous capability

    DRDO/SSPL/GAETEC work towards indigenous GaN MMIC and device technology.

    3. Indian academic research matures

    IISc spends years developing GaN materials, devices and fabrication expertise.

    4. Research becomes entrepreneurship

    AGNIT emerges as an IISc spin-off.

    5. The startup develops actual products

    AGNIT moves from wafers and prototypes to commercial RF devices.

    6. Qualification infrastructure appears

    AGNIT establishes its own GaN testing and qualification laboratory at IISc.

    7. Defence and telecom become markets

    GaN becomes relevant not only to strategic systems but also to telecom and other high-power/high-frequency applications.


    And there is one more important dot

    The Indian semiconductor story is no longer restricted to individual laboratories or startups.

    The government is attempting to create a broader semiconductor manufacturing ecosystem.

    That matters because a semiconductor startup cannot become strategically important if the surrounding manufacturing ecosystem doesn't exist.

    You need:

    • wafer fabrication
    • epitaxy
    • packaging
    • testing
    • qualification
    • equipment
    • materials
    • skilled engineers
    • government procurement
    • private capital
    • large customers

    Only when these pieces connect does a country move from:

    "We can design it."

    to

    "We can make it."

    and eventually:

    "We control the technology."


    The AGNIT story is therefore bigger than one startup

    AGNIT's importance isn't simply that it is producing GaN devices.

    It represents a possible technology-transfer pipeline from Indian scientific research into industry.

    Think of the architecture:

    IISc


    fundamental research

    Indian semiconductor process technology

    AGNIT


    commercial products

    Defence / Telecom / Space / RF systems

    That is precisely the kind of ecosystem India needs.

    And this is why the story should not be reduced to:

    "France refused to give India GaN technology."

    The much bigger story is:

    India developed the scientific capability to reproduce and commercialise a strategically important technology instead of remaining permanently dependent on the country that possessed it.


    France and India: the irony

    There is also an interesting geopolitical twist.

    France and India today have an increasingly deep strategic relationship.

    So this isn't really a story about India "defeating France".

    It is a story about strategic autonomy changing the nature of partnerships.

    A technologically dependent country negotiates from a position of weakness.

    A technologically capable country can collaborate from a position of strength.

    That distinction matters enormously in defence.


    From buyer to technology partner

    This is ultimately what India's semiconductor strategy should be about.

    Not merely:

    "How many fabs can India build?"

    But:

    "How many critical technologies can India understand deeply enough that denial no longer cripples us?"

    GaN is a perfect example.

    A technology that was once difficult to access becomes an Indian research problem.

    The research becomes an Indian engineering capability.

    The engineering capability becomes a startup.

    The startup develops products.

    Products enter strategic markets.

    And the surrounding ecosystem begins to grow.

    That is how technological sovereignty is built.

    Not overnight.

    Not through slogans.

    But through 15–20 years of scientific research, engineering, failed experiments, prototypes, manufacturing, testing, capital and persistence.


    The real lesson

    The most important line in this entire story may therefore be:

    Technology denial can delay technological progress. It does not necessarily prevent it.

    India's GaN journey illustrates something deeper about national technological development.

    DRDO brings strategic mission and defence requirements.

    IISc provides deep scientific research.

    AGNIT provides the entrepreneurial bridge.

    Capital provides scale.

    Testing and qualification provide industrial credibility.

    Government policy provides ecosystem support.

    And the final objective is not merely to manufacture a GaN chip.

    It is to create an ecosystem in which the next generation of strategic semiconductor technology can be developed inside India.

    That is the real meaning of semiconductor sovereignty.

    And perhaps the most fascinating part of the story is this:

    The answer to "Can India build it?" is increasingly becoming — "Give the Indian scientists enough time."

    Wednesday, July 29, 2026

    When a Bridge Becomes a PhD: Is China Redefining Doctoral Education?

    For generations, the image of a PhD has remained almost unchanged.

    Years of research. Hundreds of pages of dissertations. Endless citations. A thesis read by only a few experts.

    But what if a doctorate could be earned by building something that changes the real world instead?

    China is testing that idea.

    A Different Definition of Research

    Under 2024 reforms, selected Chinese universities can award engineering doctorates based on practical technological achievements, not just dissertations.

    Instead of “What did you write?”, the question becomes:

    “What did you build that works?”

    The First Graduates

    The results are already drawing attention.

    Zheng Hehui designed interlocking steel blocks used in the Changtai Yangtze River Bridge, the world’s longest cable-stayed bridge.

    Wei Lianfeng developed vacuum laser welding techniques for China’s nuclear industry.

    Others have built firefighting systems for seaplanes and solved major industrial engineering problems.

    Their theses are now working technologies.

    Bridging Academia and Industry

    A long-standing issue in engineering education is the gap between research and industry.

    Universities reward papers. Industry rewards products.

    China’s programme aims to merge the two.

    Since 2022, over 60 universities and about 100 companies have joined, with thousands of students working on industry-linked doctorates in fields like AI, semiconductors, aerospace, and energy.

    Is This Really New?

    Not entirely.

    Many countries already have industry PhDs and professional doctorates.

    The difference is scale: a deployed technology or prototype can now serve as the core proof of a doctorate, not just a written thesis.

    The Potential Advantages

    • Solves real industrial problems
    • Speeds up technology transfer
    • Strengthens university–industry ties
    • Prepares engineers for real-world innovation
    • Emphasises measurable impact

    But There Are Challenges

    Traditional PhDs create a permanent academic record.

    A prototype may not fully explain why it works or advance theory in the same way.

    Key questions remain:

    • How is originality judged?
    • How is work verified?
    • What ensures academic rigour?
    • Does secrecy limit openness?

    This model may complement, not replace, traditional PhDs.

    Should Other Countries Follow?

    Many countries already have strong dissertation-based systems that drive major scientific breakthroughs.

    But engineering ultimately meets practice.

    The future may require both:

    • rigorous research
    • and real-world impact

    A bridge that lasts decades may represent knowledge as much as a written thesis.

    Final Thoughts

    China’s experiment challenges the idea that a dissertation is the only path to a PhD.

    Whether it spreads globally is unclear. But it raises a key question:

    In engineering, should we value pages written—or problems solved?

    Perhaps the best PhDs combine both.

    From Bharat's perspective...

    My POV...

    Monday, July 20, 2026

    Vimag Labs’ Magnetless Motor Breakthrough: India’s Software-Defined Challenge to Rare-Earth Dependence...

     In the electric vehicle (EV) world, rare-earth permanent magnets have long been the hidden bottleneck. They deliver the high efficiency and torque that power most modern EVs, but they come with massive supply-chain risks—China dominates ~90% of rare-earth processing and a huge share of the high-performance NdFeB magnets used in motors.

    A Bengaluru-based deep-tech startup called Vimag Labs (sometimes associated with the Volektra brand) claims to have cracked a compelling alternative: a Virtual Magnet Synchronous Motor (VMSM) that eliminates rare-earth magnets entirely by using software, power electronics, and clever electromagnetic design.

    What Is a Magnetless (or “Virtual Magnet”) Motor?

    Traditional Permanent Magnet Synchronous Motors (PMSMs) embed strong rare-earth magnets in the rotor. These create a fixed magnetic field that interacts with the stator’s rotating field to produce torque. It’s efficient, compact, and powerful—but dependent on critical minerals.

    Vimag’s VMSM removes those physical magnets. Instead:

    • It uses a brushless, slip-ring-free architecture.
    • A rotating transformer (patented) wirelessly transfers power to the rotor.
    • Proprietary control algorithms and power electronics dynamically generate and control the rotor’s magnetic field in real time—essentially creating a “virtual magnet” whose strength and behavior can be tuned on the fly.

    The result, according to the company, is a synchronous motor that matches or exceeds the performance of traditional PMSM designs in efficiency, torque, and power density—while using only common materials like copper and steel.

    The Latest Milestone: Fifth Indian Patent

    In July 2026, Vimag Labs was granted its fifth Indian patent, titled “A Robust Rotating Transformer Excited Synchronous Motor and Its Control.” This protects the core architecture of the VMSM platform.

    The company now has:

    • 5 granted patents
    • 10 additional patent applications
    • 15 trademarks

    This IP covers motor design, software controls, power electronics, and application-specific tweaks. CEO and co-founder Manish Seth (with prior experience at Volkswagen, Ford, and GM) noted the patent represents over 87,600 engineering hours.

    Why This Matters — Strategic and Commercial Angles

    Supply Chain Independence
    By going magnet-free, Vimag reduces exposure to geopolitical risks and price volatility in rare-earth materials. This is especially relevant for India and any nation seeking to localize EV manufacturing.

    Cost and Flexibility
    No rare-earth magnets can lower bill-of-materials costs. The software-defined nature also opens the door to performance improvements via firmware updates rather than hardware redesigns.

    Target Applications

    • Two-wheelers and passenger vehicles (current pilots)
    • Light & heavy commercial vehicles
    • Industrial systems (200–600 kW)
    • Robotics, defense, and cooling systems

    Vimag recently raised $5 million in Series A funding led by Accel, with participation from Chakra Growth Fund and Thinkuvate. They’ve also signed a manufacturing MoU with Jendamark to support scale-up.

    Challenges and Realistic Outlook

    This is still early-stage technology. While the claims are impressive—matching or beating PMSM performance without magnets—the technology has not yet been independently verified at full production scale. Many magnetless or reduced-rare-earth approaches (induction motors, switched reluctance motors, etc.) have historically traded off efficiency, torque density, or added complexity like brushes/slip rings.

    Vimag’s brushless rotating-transformer approach aims to avoid those classic downsides. Success will depend on real-world validation in pilots, thermal management, long-term reliability, and cost at volume.

    The Bigger Picture

    Vimag Labs, founded in September 2025, is part of a growing wave of innovation seeking to make EVs less dependent on a handful of critical materials. If the VMSM platform delivers on its promises, it could accelerate India’s (and the world’s) ability to build high-performance electric motors domestically—using software smarts instead of imported magnets.

    The road from promising patent to mass-market adoption is long, but the direction is exciting: turning the motor itself into a software-defined component.

    Watch VIMAG...

    I am sure it will be worthy your time...

    Jai Hind...