BeamDesk Radar

We said no one was working on this. Someone is.

2026-09-02T00:00:00Z

For the last two weeks our gap analysis has carried a sentence saying that the power-beaming field is fragmenting, with at least two mutually incompatible physical layers being flown or funded, and no venue where their interfaces are being reconciled.

The second half of that was wrong, and had been for about two years.

What we missed

LOGIC — the Lunar Operating Guidelines for Infrastructure Consortium — is sponsored by DARPA and managed by the Johns Hopkins Applied Physics Laboratory. It has over 900 members and exists, in its own words, to bring the lunar community together around "adopting, adapting and potentially authoring interoperability standards."

It has a Power working group. That group has ten numbered use cases, and each one carries a published status pipeline that ends in *Ready for SDO Review* — submission to standards development organisations.

Use case P5 is Wireless Rover Charge, last updated in May 2026:

> As a Power Consumer, I want to request power from the grid and receive power via power beaming at a specified location to charge my onboard battery pack.

Its assumptions distinguish short-range induction from "long distance (e.g. laser and microwave)". Its scenarios include human-rated transmission safety. And its working notes pose this question:

> The power beaming supplier said they delivered 100% of the requested power, but my vehicle's telemetry says it only received 80% of the requested energy. Who is responsible for the difference? Who mediates disputes?

Why we missed it

Every row in our survey asks a question of a standards body or a regulator — the ITU, the IEEE, CCSDS, ICNIRP, the FCC. Not one asked whether a consortium had taken the ground. A consortium is what did.

That is a flaw in the method rather than bad luck. A register that only interrogates the bodies that publish finished standards will systematically miss the places where standards are being drafted, and drafting is the stage where an interface is actually decided.

What still holds

No standard has been published. LOGIC's own P5 page is the evidence: under *Recommendations for Standards to Be Authored* it currently reads "In progress", and the existing standards it can point at are close-proximity induction and electric-vehicle charging — ISO/IEC 17568, SAE J2954, SAE J2847/6, IEEE 2030-2011. None of those governs a laser or a microwave beam over a kilometre.

So the absence of a published standard, which is what our survey was built to establish, is unaffected. What we asserted without establishing was the absence of *activity*, and that assertion is now withdrawn and recorded as withdrawn.

What we are doing about it

Our specification says in its own status section that where a recognised body opens relevant work, the document should be contributed there and the project archived — and that the authors would prefer that outcome to adoption of their own draft. We meant it. LOGIC has opened relevant work, so the next move is to take part in it rather than to publish alongside it.

If you are tracking this field and you were relying on our claim that nobody was coordinating it, correct that. And if you keep a register of your own, the lesson generalises: ask consortia, not only the bodies that publish.

Where to read it

https://logic.jhuapl.edu/
https://logic.jhuapl.edu/Our-Work/Standards-Recommendation/P5.-Wireless-Rover-Charge_830603446.html
https://logic.jhuapl.edu/Our-Work/LOGIC-Power-Report-Styling.pdf — *Lunar Power Infrastructure Standards: Initial Assessment*
https://github.com/BeamDesk/beamed-power-interface/blob/main/gap-analysis.md — the register, with the withdrawal recorded

Ground stations are not antennas

2026-08-25T00:00:00Z

AWS Ground Station's user-guide document history records, dated 14 April 2026, documentation for two new operations: ListAntennas and ListGroundStationReservations. Separate entries the same day cover Dedicated Antennas and contact versioning.

Both new operations are GETs. For anyone proxying this API read-only — forwarding GET and refusing everything else, so that a console cannot be one fetch away from booking billable antenna time — that means the new surface is reachable with no change to the proxy at all. The guarantee is about the method, not about an endpoint list, which is why the list growing does not weaken it.

The part worth repeating

Until April there was no operation that returned an antenna list. If you wanted a sense of the size of the network, ListGroundStations was what existed, and counting its results was the only thing available.

A ground station is a site. A site hosts one or more antennas. So a count of ground stations presented as a count of antennas is not a rounding error in the label — it is an undercount, by a factor that varies per site and that nobody can see from the number.

That was forgivable shorthand while the honest number did not exist. It stopped being forgivable in April, and it stopped being merely pedantic on the same day, because Dedicated Antennas makes the distinction commercially real: an antenna is now a thing you can hold exclusively, which means it is a thing worth counting correctly.

We were doing this. Our own data-sources panel reported a ground-station count under the word "antennas". We have corrected the noun, and the true count is a fan-out away for whoever wants it.

If you have a dashboard with an antenna count on it, this is worth ten seconds of checking where the number came from.

Where to read it

Also this week

The catalogue-number transition is now documented by a third major provider. AWS wrote the 100,000-object catalogue transition into its own documentation in May, following CelesTrak in July and N2YO in July. The conclusion has been the same each time and can now be stated as a settled rule rather than rechecked: systems that carry catalogue numbers as numbers, from a structured feed, are unaffected. Systems that parse them out of fixed columns in legacy two-line element text are not, because that format cannot represent a number above 99,999. If you still have a TLE text parser on a live path, it is on a clock.

Checked and unchanged: all six ITU-R propagation recommendations we cite, ICNIRP 2020, and IEEE Std C95.1-2019.

Checked and not verifiable: the CCSDS publications host has refused our fetcher for eight consecutive days. That is recorded as unchecked rather than unchanged. A 403 is not a 404, and the difference matters — one means nothing has changed, the other means we do not know.

ITU names the bands for power beaming. That is not permission.

2026-08-22T00:00:00Z

ITU-R published a new edition of Report SM.2392, "Applications of wireless power transmission via radio frequency beam", dated June 2026. It supersedes the 2021 edition. A five-year gap usually means a substantive revision rather than an editorial one, and this one is substantive: Section 5 addresses spectrum for RF-beam wireless power transfer, and Section 2.9 is titled "Space based solar power via satellite".

Section 5 names 915 MHz, 2.45 GHz, 5.8 GHz and 24 GHz as the bands used for RF-beam power transfer, and observes that 2.45 GHz is more desirable than the higher bands because propagation impairments are smaller.

For anyone working on power beaming this is a genuinely useful document. It is the ITU's own text describing the application, and until now much of the frequency discussion in this field cited nothing at all.

What it is not

It is a Report. Reports are not Recommendations. A Recommendation is a technical standard that other instruments incorporate by reference; a Report describes a state of affairs. SM.2392 recommends nothing and binds nothing.

That distinction is the entire content of this edition, and it is going to be misread. The tempting inference — ITU has named 5.8 GHz for space-based solar power, therefore 5.8 GHz is available for space-to-Earth power beaming — does not follow, and it is worth being blunt about why.

5.8 GHz sits in an ISM band. The Radio Regulations carry no Article 21 space-to-Earth power-flux-density row for it, and the Radio Regulations do not contemplate a space station transmitting at these power levels into it. A Report naming the band as the one the field uses is a description of engineering practice. It is not a spectrum allocation, it is not a change to Article 21, and nobody should build a regulatory assumption on it.

We filed it in our own standards registry as vocabulary — a document we cite for its terms, not one we execute — and left our Article 21 caveat standing unchanged.

The narrower point about corroboration

Section 2.9 describes a geostationary system. Most published work on beamed power at scale is GEO, and ground-footprint figures follow from aperture and range.

So if you fly in low Earth orbit and one of ITU's stated areas happens to match a number in your own model, that agreement is a coincidence of scale across a link two orders of magnitude different in range. It is not the ITU validating the LEO case. Take the citation for what it covers and no further.

Where to read it

https://www.itu.int/dms_pub/itu-r/opb/rep/R-REP-SM.2392-2-2026-TOC-HTM-E.htm

One related document worth ruling out explicitly: ITU-R SM.2151 is the Recommendation on frequency ranges for RF-beam wireless power transfer, and would be the load-bearing instrument if it applied. It does not. Its title scopes it to mobile and portable devices and sensor networks, it has not been revised since 2022, and it says nothing about space-to-Earth power.

Also checked this week and unchanged: all six ITU-R propagation recommendations we cite, ICNIRP's 2020 RF guidelines, and IEEE Std C95.1-2019.

A ground-segment API you can read before you sign

2026-08-19T00:00:00Z

Commercial ground-segment-as-a-service has a quiet convention: the interface arrives with the contract. You can read the marketing, you can read a datasheet, and you find out what the API actually looks like once you are a customer. That convention is load-bearing for anyone building against these vendors, because it means integration cost is unknowable until after the commercial decision is made.

SSC has broken it, in the useful direction.

What is published

Space Go is SSC's self-service offering on 4 m-class S/X/Ka antennas at five sites: Esrange in Sweden, Alaska, Inuvik in Canada, Western Australia, and Punta Arenas in Chile.

The documentation is open and unauthenticated, and it includes an External ICD, a full API reference, a hardware specification, terms, and — the part that matters most — a sandbox ICD.

Read from the reference rather than the marketing:

A versioned base path, with a separately addressed sandbox environment.
Authentication is HTTP Bearer with a JWT, or OAuth 2.0 authorization-code against a tenant token endpoint. There is no anonymous route.
Endpoints cover contacts (list with time filtering, create, fetch, delete), contact availability, sites, spacecraft, spacecraft TLE upload and retrieval, service configuration, and post-contact reports.

The interesting omission

There is no pass-prediction endpoint, and the documentation is explicit that this is deliberate: the customer computes visibility from element sets and then validates the result against the availability endpoint.

That is worth dwelling on, because it is a statement about where the division of labour sits in this market. The vendor sells antenna time and tells you when it is free. Working out when a spacecraft is overhead is your problem, and the vendor assumes you have already solved it. Any architecture that expected the ground network to answer "when can I talk to my satellite" is building against an assumption these vendors do not share.

It also means an integration is two independent halves — your own propagation, and their availability — which can be built and tested separately. The sandbox makes the second half testable without a contract.

Where to read it

https://go.sscspace.com/docs/api_doc_external/

The terms are ordinary commercial contract language. Nothing in them restricts building against the sandbox.

The ITU revisions actually in force

2026-08-13T00:00:00Z

A link budget is only as current as the recommendation it cites. Three of the documents this field leans on hardest were revised recently enough that a citation written in good faith two years ago now names a superseded edition.

What changed

ITU-R P.837 is now at revision 8, approved September 2025. P.837 is the rainfall-rate recommendation — the one that feeds rain attenuation at every frequency where rain matters. The previous revision, P.837-7, dates from June 2017 and is marked superseded on the ITU's own page.

ITU-R P.525 is now at revision 5, approved November 2024, replacing P.525-4 from August 2019. This is free-space path loss. The formula is not going to surprise anyone, but the document that carries it has moved.

The Radio Regulations are at the Edition of 2024, incorporating the Final Acts of WRC-23 and superseding the Edition of 2020. WRC-23 also adopted Resolution 775, which concerns power-flux-density and e.i.r.p. limits for inclusion in Article 21 at 71–76 and 81–86 GHz.

Why it matters more than a version number

For P.525 the substance almost certainly did not move. For P.837 it might have: the underlying rainfall dataset is the whole content of the recommendation, and a revision after eight years is not usually editorial.

The Radio Regulations case is different again, and it is the one worth care. An edition change to the Radio Regulations is not a citation-hygiene problem — it is a change to what is permitted. If your product screens a transmission against an Article 21 limit, the table you implemented and the table now in force are two different objects until someone reads Volume 1 of the 2024 edition and confirms otherwise. We treat the edition string as confirmed stale and the numeric limits as unverified until that reading happens, and we would suggest anyone else in the same position does the same.

We re-pinned all three.

Where to read it

ITU-R P.837: https://www.itu.int/rec/R-REC-P.837/en
ITU-R P.525: https://www.itu.int/rec/R-REC-P.525/en
Radio Regulations: https://www.itu.int/pub/R-REG-RR

Checked the same day and unchanged: P.676-13, P.618-14, P.838-3, P.839-4, ICNIRP's 2020 RF guidelines, and IEEE Std C95.1-2019.