Three surfaces that report confidently and wrongly: `get radio`.`txPower`, `get meters`.`sLevel`, and the noise-blanker comment in `Hl2RxDsp::setAudioMuted`

[on8st]

Report preparation

• I used the AI-assisted bug report tool (Help → Support → File an Issue)
• I have attached a support bundle or log file

What happened?

Three surfaces in the app report confidently and wrongly, with no failure
visible from outside. Each is the documented, obvious thing an operator or an
instrument would reach for. Each answers plausibly. None of them answers.

They are filed together because they are one class and because a maintainer
fixing one will already be in the files the next one lives in.

The class has a name in this codebase already. Two lines above one of the fields
below, metersSnapshot says:

Null rather than a stale ratio, matching the SWR entry in all and the
fwdPower/reflectedPower pair above — a client reading this scalar must not
get a different answer from the one reading the array (#4533).

That is exactly the rule all three break. swr got the treatment; the field on
the next line did not.

All three were found on a Hermes-Lite 2 during a measurement run on the
operator's own radio, keyed into a dummy load at 10% drive (of order 0.15 W
forward, uncalibrated). None of them required transmitting to establish; two of
them are visible from a receiving radio and one from source alone. The keying is
mentioned because it is how the first one was caught in the act.

---

1. get radio.txPower is a constant 0.0 whatever the drive is

RadioModel::m_txPower is declared

float       m_txPower{0.0f};

in RadioModel.h and is assigned nowhere in the tree. The only writes to a
symbol of that name are SMeterWidget's own, unrelated member. RadioModel::txPower()
returns it, AutomationServer's radioSnapshot publishes it as txPower, and
the property declaration is

Q_PROPERTY(float   txPower     READ txPower     NOTIFY metersChanged)

— so it advertises a freshness it cannot have. metersChanged will fire; the
value behind it never moves.

Proved live, not only from source. With get transmit.rfPower reading 10,
the tone modulating, the relay thrown and 0.153–0.184 W measurably going into the
dummy load on all three keyed windows, get radio.txPower read 0 on every
sample.

The tree already believes this field is live. Hl2Backend's own drive
telemetry block — the one added under #4912 precisely to stop automation trusting
a readback that shares the failure it is checking — says:

Nothing anywhere reported the APPLIED drive. get transmit has rfPower and
get radio has txPower, but both read TransmitModel — the operator's
request — which is exactly the readback-shares-the-failure problem this section
exists to solve.

Only the first half is true. get radio.txPower reads RadioModel, not
TransmitModel, and reads a field nothing writes. A comment written to warn
about an over-trusted readback names a field that is worse than the one it warns
about.

What it cost here. An earlier run of ours gated on this field: it asked for
a drive and read it back before keying, which is the right shape of gate. The
gate was incapable of failing — it compared 0 against 0. A later run asked
for drive 10, read back 0, and correctly refused before the first key; it was
only in working out why that the field turned out to be dead. So one of our own
published runs carries a "drive set and read back" sentence that is a
coincidence, and has been withdrawn.

The live field is TransmitModel::m_rfPower, written by
TransmitModel::setRfPower and also assigned from the radio's own status in
TransmitModel::applyStatus, published as get transmit.rfPower.

Suggested remedy: populate m_txPower from the value TransmitModel already
carries, or drop the field from radioSnapshot entirely so a client cannot
read it. Either is fine. Two readings in one app disagreeing is not.

---

2. get meters.sLevel is dead on this backend — a constant −130 dBm

MeterModel::m_sLevel is declared {-130.0f} and assigned in exactly one
place: MeterModel::clear, to -130.0f. The meter-packet path never touches
it. A per-slice LEVEL meter is recognised through m_sLevelIdxBySlice, and that
branch stores the value in m_values[idx] and emits sLevelChanged(slice, v) —
which is what MainWindow::wireMeters carries to SMeterWidget::setLevel. The
scalar is not on that path.

metersSnapshot publishes {"sLevel", m->sLevel()} regardless.

Measured. One 14-second pass, six legs, radio receiving normally throughout:
1304 samples of get meters.sLevel, every one of them exactly −130 dBm,
zero distinct values other than that. On the control leg alone that is 212
identical samples over 14.03 s. The live level in the same session, read from the
SLC:LEVEL row of the same reply's all array, sat at a median of
−83.9 dBm (214 samples).

So the working path exists, in the same reply, two fields away. This named field
is simply not on it.

Suggested remedy: populate the scalar from the same per-slice value the array
carries, or publish it as null rather than −130, so a client can tell "the
radio never told us" from "the signal is at the bottom of scale". That is the
distinction metersSnapshot already draws for swr, and which #4533 settled for
that field.

Related, and reported separately because it is a different quantity: the
SLC:LEVEL row itself is published outside its own declared range.
Hl2Backend::defineMeters declares it −140…0 dBm, and during a transmission the
smoothed value reaches −252 dBm — Hl2Backend::addReceiver's EMA runs on the raw
dBm with no clamp. Noted here only so a maintainer touching this file sees both.

---

3. Hl2RxDsp::setAudioMuted's comment inverts the code it points at — and the mitigation it describes is inert with the noise blanker off

Hl2RxDsp::setAudioMuted ends:

// ... Holding it freezes the average instead; WdspChannel flushes it on release.

WdspChannel::processIq's hold-release branch says the opposite, in terms:

// DELIBERATELY NOT FLUSHED on the way out of a hold, and this is
// the whole point of holding rather than muting. The stage was
// SKIPPED while held, not fed, so its running average still holds
// the pre-transmit signal level and it is already armed for the
// first receive sample.

and then argues it at length with measured numbers: a flush there would leave the
blanker unarmed for ~200 ms at backtau 0.05 s, giving a blanked/unblanked
impulse peak ratio of 1.000 — bit-identical to the blanker being switched off
— against 0.43 once settled, and 0.52 without the flush.

The behaviour is the deliberate, well-argued one. The comment upstream of it is
stale and inverts it. The only flush_anbEXT call in the file is in
WdspChannel::setNoiseBlanker, on enable, not on hold release.

WdspChannel::setNoiseBlankerHold's own comment carries the same wrong belief a
second time: "Both stores are atomic and the flush they schedule happens inside
processIq() itself." No flush is scheduled and none happens.

And with the blanker off, none of it runs at all. The entire hold mechanism
sits inside

if (m_nbActive.load(std::memory_order_relaxed)) {
    if (m_nbHold.load(std::memory_order_relaxed)) {

so with the blanker disabled, m_nbHold gates a stage that is not running and
the mitigation is dead code. On the station where this was found, get hostnb
read {"on": false, "requestedOn": false, "level": 50, "threshold": 20} — the
blanker is off, which is the default and is the configuration the unkey
transient in #5497 was reported and measured on. Whatever that mitigation is
worth, it is not in the path there.

Suggested remedy: correct the sentence, change no behaviour. Say what
WdspChannel actually does — the stage is skipped while held, so its running
average is preserved and it is already armed on release, and nothing is flushed.
A comment that inverts the code it points at is worse than no comment: this one
sent a bench looking through the source for a mechanism that does not exist.

---

What did you expect?

That a published field either carries a value or says it has none; that a
Q_PROPERTY declaring NOTIFY metersChanged is attached to something that
changes; and that a comment describing a neighbouring class's behaviour matches
that behaviour.

Steps to reproduce

1 — Connect a Hermes-Lite 2. Set a transmit drive: set transmit rfpower=10.
Read both fields:

get transmit   ->  "rfPower": 10
get radio      ->  "txPower": 0

The second stays 0 at every drive, before and during a transmission. (Confirming
that the drive is really applied needs a physical witness — here, forward power
present on the load while keyed.)

2 — With the radio receiving normally, poll get meters and compare the two
places the same quantity is published:

get meters   ->  "sLevel": -130          (constant, always)
             ->  "all":  { source "SLC", name "LEVEL" }  ~ -84 dBm, moving

3 — Source-only, no radio needed: read the last sentence of
Hl2RxDsp::setAudioMuted, then read the hold-release branch of
WdspChannel::processIq and grep flush_anbEXT over WdspChannel.cpp.

AetherSDR version

26.9.1 (built from source at 63a4a2e9, stock and uninstrumented)

Radio model & firmware

Hermes-Lite 2, gateware 74.2 (20231230_74p2_883a338)

Operating system

macOS

OS version and hardware

macOS 26.6.2, Apple M2, Qt 6.8.3

---

What was NOT measured

• HL2 only. sLevel and the Hl2RxDsp/WdspChannel pair are backend-scoped
  by construction. RadioModel::m_txPower is not — it is a model field with
  no backend in it, so if it is dead here it is dead for every radio family, but
  that is a claim about the source and it was checked on no other hardware.
• macOS only. Not built or run on Linux or Windows. Nothing above is platform
  conditioned in the source, but that is again a claim about the source.
• Whether anything else reads these fields. The consequences described are
  the ones this bench hit. No survey of consumers was done.
• Whether the noise blanker's hold works correctly when the blanker IS on.
  It was off throughout. Only the comment and the m_nbActive gate are
  established here; the argued-for behaviour is taken at its own word.
• The dummy load's power rating could not be established from any record
  available here, and the operator was not asked. Forward power is uncalibrated
  and reads only while keyed.
• No far-side observer. Nothing here says what any other station heard.

Citations

By file and symbol; no line numbers.

• src/models/RadioModel.h — the m_txPower member declaration, RadioModel::txPower,
  and the Q_PROPERTY(float txPower READ txPower NOTIFY metersChanged)
• src/core/AutomationServer.cpp radioSnapshot — the txPower entry
• src/models/TransmitModel.cpp TransmitModel::setRfPower and
  TransmitModel::applyStatus — the live field
• src/core/backends/hl2/Hl2Backend.cpp — the drive-telemetry comment block that
  names txPower as reading TransmitModel; and Hl2Backend::defineMeters for
  the SLC:LEVEL −140…0 dBm range
• src/models/MeterModel.cpp MeterModel::clear (the only assignment to
  m_sLevel) and the meter-packet loop that recognises m_sLevelIdxBySlice and
  emits rather than stores
• src/models/MeterModel.h — the m_sLevel declaration and MeterModel::sLevel
• src/gui/MainWindow_Wiring.cpp MainWindow::wireMeters —
  MeterModel::sLevelChanged → SMeterWidget::setLevel, the path the scalar is
  not on
• src/core/AutomationServer.cpp metersSnapshot — the sLevel entry and the
  #4533 comment two lines above it
• src/core/backends/hl2/Hl2RxDsp.cpp Hl2RxDsp::setAudioMuted — the wrong
  sentence
• src/core/dsp/WdspChannel.cpp WdspChannel::processIq (the hold-release branch
  that does not flush, and the m_nbActive gate above it),
  WdspChannel::setNoiseBlankerHold (the second wrong sentence),
  WdspChannel::setNoiseBlanker (the only flush_anbEXT, on enable)

Related: #4533 (the swr scalar, the precedent this cites), #5370 (HL2 TX Delay
— the same "the control is present, editable and looks functional" shape on the
GUI side rather than the automation side), #4957 (a stale comment naming a path
that has not existed since #4545).

🤖 Generated with Claude Code

https://claude.ai/code/session_014TtnKQu6QGrSeBirGeAsAs

[aethersdr-agent]

Triage: all three confirmed against main (293240a7). Adding two things the report doesn't have — a fourth instance of the same defect one line away from the first, and a consumer of #2 outside the automation API that the report's "no survey of consumers was done" caveat left open. That consumer changes the severity.

---

1. get radio.txPower — confirmed, and it was never alive

src/models/RadioModel.h:1741 declares float m_txPower{0.0f}; git log -S over the file's whole history finds no write, ever. It was born dead in 6af248bd alongside the getter (RadioModel.h:189) and the property (RadioModel.h:85):

Q_PROPERTY(float   txPower     READ txPower     NOTIFY metersChanged)

Published at AutomationServer.cpp:1855. Every other m_txPower hit in the tree is SMeterWidget's unrelated member (written from setTxPowers) or RadioModel::m_txPowerBands. So this is not a regression to bisect — there is nothing to restore, only a decision to make.

The Hl2Backend.cpp:4288 comment is wrong exactly as described:

get transmit has rfPower and get radio has txPower, but both read TransmitModel

get radio.txPower reads RadioModel. That comment needs correcting whichever remedy is chosen, since #4912 justifies a whole telemetry block partly on a claim about a field that doesn't do what it says.

1b. get radio.paTemp is dead in exactly the same way (not in the report)

The line directly above, AutomationServer.cpp:1856, publishes r->paTemp() → RadioModel.h:1740 float m_paTemp{0.0f}, also never assigned anywhere, also Q_PROPERTY(... NOTIFY metersChanged) at RadioModel.h:84.

And as with sLevel, the working value is in the same neighbourhood: MeterModel::m_paTemp is live (written at MeterModel.cpp:864 from the RAD:PATEMP meter) and is published correctly at AutomationServer.cpp:2213 and RadioModel.cpp:11992. So get radio.paTemp reads a constant 0.0 while get meters.paTemp reads the real PA temperature — the same two-readings-disagree failure, same function, same pattern. Whatever is done to txPower should be done to this in the same change.

2. get meters.sLevel — confirmed, and the regression has a specific origin

Confirmed: the only assignment to MeterModel::m_sLevel is MeterModel.cpp:396 in clear(), to -130.0f.

The report treats this as "the scalar is simply not on the path." It's narrower than that — it used to be, and one commit removed the write. e6323978 ("Fix S-meter showing only newest slice's signal level", #155) converted the single m_sLevelIdx into m_sLevelIdxBySlice and, in the same hunk, deleted the store:

-        if (idx == m_sLevelIdx) {
-            m_sLevel = v;
-            sChanged = true;
+        // Check if this meter is a per-slice LEVEL meter
+        bool isSliceLevel = false;
+        for (auto sit = m_sLevelIdxBySlice.constBegin(); ...) {
+            if (sit.value() == idx) {
+                emit sLevelChanged(sit.key(), v);

The per-slice fix was correct; the scalar getter and its callers were just left behind pointing at a member nothing writes any more. That makes this a clean regression with a known culprit, not a design gap.

The consumer that matters: rigctl get_level STRENGTH is a constant

RigctlProtocol.cpp:1432-1435:

if (level == "STRENGTH") {
    // S-meter in dBm; STRENGTH is dB relative to S9 (-73 dBm on HF)
    const double strength = m_model->meterModel().sLevel() - kS9Dbm;

With kS9Dbm = -73.0 and sLevel() pinned at -130, every hamlib client asking this radio for signal strength gets exactly -57.0, always, on every backend and every radio family — not HL2-scoped, unlike the rest of item 2. That is WSJT-X, N1MM, gpredict, anything driving AetherSDR over rigctl. This is why I've put priority: medium on the issue rather than leaving it unset: it's a silently broken user-facing feature with a wide blast radius, and it's the same one-line fix.

MeterSurfaces.h:80 also documents SLC:LEVEL as reaching consumers via "MeterModel::sLevelChanged / sLevel()" with rendered=true. The sLevelChanged half is true; the sLevel() half is the dead path. That header's own comment says a listing here is "verified against the wiring, not assumed" — so it needs correcting too.

3. The setAudioMuted comment — confirmed, comment-only fix

• Hl2RxDsp.cpp:195 — "WdspChannel flushes it on release." False.
• WdspChannel.cpp:364-372 — the hold-release branch, "DELIBERATELY NOT FLUSHED ... this is the whole point of holding rather than muting," argued with the 1.000 / 0.43 / 0.52 impulse-ratio numbers.
• WdspChannel.cpp:814 — setNoiseBlankerHold's "the flush they schedule happens inside processIq() itself." Also false; the function only does m_nbHold.store(...).
• The sole flush_anbEXT is WdspChannel.cpp:801, inside setNoiseBlanker under if (on), i.e. on enable.
• WdspChannel.cpp:362-363 — the m_nbActive gate does enclose the m_nbHold check, so with the blanker off the hold is inert, as reported.

The report's recommendation is the right one: the code is correct, the two comments are wrong, change no behaviour. Note the inertness carefully in the fix rather than "fixing" it — someone reading m_nbHold gating a stage that isn't running may be tempted to hoist it out of the m_nbActive block, which would be a behaviour change to a real-time path with no reported problem behind it.

---

Proposed fix

Three independent, small changes; none depends on the others.

A — the dead scalars (src/core/AutomationServer.cpp, src/models/MeterModel.cpp)

Prefer populate over drop for sLevel, because rigctl STRENGTH needs a real value and dropping the field doesn't give it one. Restore the store next to the existing emit in the meter loop (MeterModel.cpp:733-736) — with the caveat that "the scalar" is now ambiguous across slices, so it should track the active RX slice, resolved the same way activeCompPeakIdx / scMicIndexForActiveTxSlice() already resolve theirs at MeterModel.cpp:700-703, not "whichever slice updated last." That is the bug #155 fixed; reintroducing it via the scalar would be a poor trade.

For txPower and paTemp in radioSnapshot, dropping is the cleaner remedy — get meters already carries both correctly, so populating RadioModel would create a second copy to keep in sync for no gain. If they're kept for compatibility, they must be sourced from MeterModel and the two Q_PROPERTY lines at RadioModel.h:84-85 removed or repointed, since a property that declares NOTIFY metersChanged over a constant is the specific thing #4533 settled against.

Also update: the Hl2Backend.cpp:4286-4294 comment, and the MeterSurfaces.h:80 entry.

B — the comments (Hl2RxDsp.cpp:195, WdspChannel.cpp:814) — reword to match processIq; no code change.

C — out of scope here, worth its own issue: the SLC:LEVEL range violation the report notes in passing. Hl2Backend.cpp:5143-5144 declares -140.0, 0.0 and the addReceiver EMA runs unclamped on raw dBm, reaching −252 during TX. Different quantity, different file, shouldn't be bundled into A.

For the maintainer

Filing all three together was the right call — A touches two files that B doesn't, but a maintainer in MeterModel/AutomationServer for the scalars is one file away from the Hl2Backend comment that misdescribes them. My suggestion is to split into two PRs: A (behaviour, needs a test that a second slice doesn't hijack the scalar, plus a rigctl STRENGTH regression test) and B+the comment corrections (zero-risk, good first issue shaped if you want to hand it off).

The one judgement call I'd flag for you: whether get radio.txPower / paTemp get dropped or populated. Dropping is a breaking change to a published automation surface, and the report explicitly did not survey consumers — I found none in-tree beyond radioSnapshot itself, but out-of-tree scripts are your call, not mine.

Not applying safety despite the report's framing. The vacuous pre-key drive gate is real and the Hl2Backend comment itself calls drive "safety-adjacent," but the defect is a readback reading zero — it can't command power, and a gate comparing 0 against 0 fails closed for any nonzero threshold. Worth stating plainly in the fix; not an equipment-protection defect.

---

_{🤖 aethersdr-agent · cost: $3.2630 · model: claude-opus-5}

---

_{📍 Citation health check (Foundry Constitution Principle I): 1 resolved, 23 unresolved against /Users/aetherclaude/workspace/AetherSDR at origin/main.}

Unresolved citations (23)

Citation	Reason
AutomationServer.cpp:1855	file not found in workspace
AutomationServer.cpp:1856	file not found in workspace
AutomationServer.cpp:2213	file not found in workspace
Hl2Backend.cpp:4286-4294	file not found in workspace
Hl2Backend.cpp:4288	file not found in workspace
Hl2Backend.cpp:5143-5144	file not found in workspace
Hl2RxDsp.cpp:195	file not found in workspace
MeterModel.cpp:396	file not found in workspace
MeterModel.cpp:700-703	file not found in workspace
MeterModel.cpp:733-736	file not found in workspace
MeterModel.cpp:864	file not found in workspace
MeterSurfaces.h:80	file not found in workspace
RadioModel.cpp:11992	file not found in workspace
RadioModel.h:1740	file not found in workspace
RadioModel.h:189	file not found in workspace
RadioModel.h:84	file not found in workspace
RadioModel.h:84-85	file not found in workspace
RadioModel.h:85	file not found in workspace
RigctlProtocol.cpp:1432-1435	file not found in workspace
WdspChannel.cpp:362-363	file not found in workspace
WdspChannel.cpp:364-372	file not found in workspace
WdspChannel.cpp:801	file not found in workspace
WdspChannel.cpp:814	file not found in workspace

[aethersdr-agent]

Antares Detector — candidate vulnerable file(s)

• src/core/backends/hl2/Hl2RxDsp.h
• src/core/backends/hl2/Hl2RxDsp.cpp

The Hl2RxDsp class declares a public Q_INVOKABLE void setAudioMuted(bool muted) and exposes it to callers; the backend code invokes this method on the receive DSP via queued connections (e.g., Hl2Backend::invokeMethod(...,"setAudioMuted", ...)). Whether safe is untrusted mute input validation, unsafe deserialization/path traversal, or other dangerous use of external-controlled values reaching a risky operation.

_{Localized by Cisco Foundation AI Antares-1B running locally in the AetherClaude sandbox, seeded by the Cartographer security map. Advisory only — please verify before acting.}

---

_{🤖 aethersdr-agent · cost: $3.3453 · model: claude-opus-5}

[on8st]

One cross-reference, so the S-meter half of this issue and the S-meter half of
#5497 are not fixed twice or half each. No new measurement here — this is
bookkeeping between two open issues.

The triage on #5497 independently confirmed item 2's "related" paragraph.
That paragraph noted that the SLC:LEVEL row itself is published outside its own
declared range, because Hl2Backend::addReceiver's EMA runs on the raw dBm with
no clamp against a Hl2Backend::defineMeters declaration of −140…0 dBm. The
#5497 triage reached the same conclusion from the other direction and proposed
clamping the EMA to the declared range. So that item now has two issues pointing
at it and a proposed remedy in the one where it is a footnote.

Two things follow that are worth having written down before either is
implemented.

1. The two proposed remedies would disagree about how "no signal" is
published. This issue's suggested remedy for the dead MeterModel::m_sLevel
scalar is "publish it as null rather than −130, so a client can tell 'the
radio never told us' from 'the signal is at the bottom of scale'" — the
distinction metersSnapshot already draws for swr and that #4533 settled.
#5497's remedy for the array row is a clamp to −140. If both land as written,
the same quantity answers null in one field and a clamped −140 in the other,
which is the two-readings-disagree failure this issue is about, reintroduced by
its own fix. Whichever is chosen, it should be chosen once for both.

2. The clamp and #5497's fix 2 address the same symptom at different depths.
The #5497 triage's own account of the −252 dBm figure is that it is an artefact
of the zero-fill — meterUpdate is emitted from the muted path with
SignalPeak taken on silence. Its proposed fix 2 (hold the RXA chain while muted
rather than clocking it with zeros) therefore removes the out-of-range excursion
at source: the meter stops being fed four seconds of silence, so the EMA
stops being walked off the bottom of the scale in the first place. A clamp bounds
the published value; the hold removes the reason it left the range. They are not
alternatives — a clamp is still correct defensively, and cheap — but a maintainer
who lands fix 2 first and then goes looking for the −252 dBm to confirm the clamp
will not find it, and should not conclude the clamp was applied.

Nothing here is a new claim about behaviour. The measurements stand as filed:
1304 samples of get meters.sLevel, every one exactly −130 dBm, against a live
SLC:LEVEL median of −83.9 dBm in the same replies.

Not verified: we cannot see your workspace or your branch state, so we do not
know whether either fix has been started. This is a note about two open issues,
not about your queue.

🤖 Generated with Claude Code

https://claude.ai/code/session_014TtnKQu6QGrSeBirGeAsAs

[on8st]

Three more items belong to the class this issue names, and collecting them makes the shape clearer than any one of them does alone. The class is: a surface that answers plausibly, is the obvious thing to reach for, and is wrong — with no failure visible from outside.

	the same shape
#5507	Radio Setup shows Region: USA on an HL2. Styled as a control, never refreshed, and fabricated — the radio has no region. The troubleshooting report says n/a for the same field, so the app contradicts itself.
#5504	The triage citation health check reports every citation as file not found in workspace against files that exist. Second occurrence. An instrument that reports confidently and wrongly about whether other reports are trustworthy.
#5642 (PR)	The fix-shaped one: health that survives disconnection. Today a disconnect leaves stale rows standing rather than absent, which is the same failure in the honest direction — a reading that is no longer true but still looks current.

The reason to see them together is not that they share code. They do not. It is that each is cheap on its own and the class is not — a maintainer fixing any one of them will already have formed the view needed for the rest, and that view is the expensive part.

What the class costs is specific: an operator or an instrument cannot tell "this is the value" from "this is what we would have said if we knew". Every one of these is a case where returning nothing, or an explicit unknown, would have been more useful than the confident answer.

#5642 is green, mergeable, and has had no human review. The three issues carry maintainer-review; #5507 is priority: low and the oldest of them is a week old.

No new work requested here — only that if one of these is picked up, the other three are much cheaper in the same sitting than in four separate ones.

🤖 Generated with Claude Code