DAILY NEWS

Stay Ahead, Stay Informed – Every Day

Advertisement
TECH & AI
Bluetooth Channel Sounding: precise BLE ranging for embedded IoT
jackminion 0



Most BLE proximity features start with RSSI. That is fine when the product only needs a rough “near or far” signal.

It becomes fragile when distance affects security, access control, asset tracking or industrial behavior.

Bluetooth Channel Sounding changes that by adding a standardized ranging capability to Bluetooth LE. Instead of relying only on received signal strength, two compatible devices exchange radio measurements that can be used to estimate distance more reliably.

Why RSSI is not enough

RSSI is easy to read, but it is not a stable distance sensor.

The value changes with antenna orientation, enclosure design, reflections, the user’s body, walls, metallic objects, interference and multipath. Two devices at the same physical distance can report very different RSSI values.

That is acceptable for simple beacons. It is not ideal for:

Digital keys and secure access
Indoor asset tracking
Smart proximity features
Find-my devices
Industrial maintenance workflows
Distance-aware IoT products

What Channel Sounding adds

Bluetooth Channel Sounding was introduced with Bluetooth Core 6.0 and refined further in Bluetooth Core 6.3.

A procedure involves two roles:

Initiator: starts the measurement

Reflector: responds to the measurement sequence

The devices exchange signals across multiple Bluetooth LE channels. The system can then estimate distance using methods such as:

Phase-Based Ranging, based on phase changes across frequencies

Round-Trip Timing, based on signal travel time between devices

The useful part is that this is not a proprietary trick layered on top of BLE. It is part of the Bluetooth specification, which matters for interoperability and long-term product design.

Where it fits

Channel Sounding is interesting when distance becomes part of the product logic.

For example:

A smart lock should know whether the authorized phone is really close to the door.
An industrial cabinet may allow access only when the technician is physically present.
A warehouse gateway may estimate how close a tag is to an anchor.
A wearable or tracker can guide the user with more useful distance feedback.
A machine can enable local configuration only when the operator is nearby.

That is different from “I can hear a BLE device somewhere nearby”. The product is now asking “how close is it, and can I trust that measurement enough to act on it?”

Architecture impact

A Channel Sounding product is not just a firmware flag. The whole embedded architecture is involved.

Area
What to verify

SoC
Real Channel Sounding support, not only generic BLE support

Bluetooth stack
Initiator, Reflector, HCI and SDK support

RF design
Antenna, layout, enclosure, ground plane and multipath behavior

Algorithm
Filtering, calibration, outlier handling and acceptance thresholds

Firmware
States, timeouts, fallback behavior and diagnostics

Security
Pairing, identity, secure boot, signed OTA and debug policy

Validation
Lab and field tests with motion, obstacles, angles and interference

This is where many projects get surprised. Ranging performance is not only about the Bluetooth version printed on a datasheet. It depends on the radio, stack, antenna, enclosure, firmware and test process working together.

Channel Sounding vs RSSI, AoA/AoD and UWB

RSSI is still useful for simple presence and low-cost beacon behavior.

AoA/AoD can be useful for localization systems that can afford antenna arrays and infrastructure.

UWB remains excellent for high-precision ranging and advanced digital-key systems, but it adds hardware, power and integration cost.

Bluetooth Channel Sounding sits in an interesting middle ground: more distance-aware than RSSI, inside the BLE ecosystem, and potentially simpler than adding a separate UWB path in products that already depend on Bluetooth.

Practical checklist

Before choosing Channel Sounding, I would check:

( ) Does the product really need distance, or is generic proximity enough?
( ) Have the RSSI failure modes been measured in the real environment?
( ) Is UWB, AoA/AoD or GNSS a better fit for the accuracy target?
( ) Does the selected SoC, controller, host stack and SDK actually support Channel Sounding?
( ) Is the antenna strategy compatible with the enclosure and installation conditions?
( ) How often will the product measure distance, and what is the battery impact?
( ) What happens when the measurement is uncertain?
( ) Are secure boot, signed OTA and debug-access policy already part of the architecture?
( ) Can field logs explain why the device trusted or rejected a distance measurement?
( ) Has the validation plan included multipath, movement, obstacles and edge cases?

Final takeaway

Bluetooth Channel Sounding is not simply “better RSSI”.

It gives embedded teams a standardized way to make Bluetooth LE devices more distance-aware. That can unlock better secure access, asset tracking, smart proximity and industrial workflows.

But it has to be designed as a system feature: hardware, RF, stack, firmware, security, power budget and validation all matter.

When those pieces are handled early, Channel Sounding can turn Bluetooth from a connectivity feature into a useful distance and trust signal for embedded IoT products.

Canonical source: Bluetooth Channel Sounding: precise and secure distance measurement for embedded IoT

Silicon LogiX helps teams design embedded, firmware and IoT architectures when prototypes need to become maintainable products.



Source link

TECH & AI
IMITATION: The Turing Test, From the Inside
jackminion 0



June Solstice Game Jam Submission

This is a submission for the June Solstice Game Jam.

What I Built

IMITATION is a browser puzzle game where you do not judge an AI.

You are the AI.

Three human interrogators question you one by one. Each asks seven questions. Every question gives you three possible answers, and every answer changes how much the judge trusts you.

Elara, the Poet rewards emotional texture and distrusts answers that feel too precise.

Dr. Voss, the Engineer rewards structure and distrusts answers that dodge the actual problem.

Mara, the Philosopher rewards doubt and distrusts certainty in either direction.

That means there is no single “best” personality to fake. An answer that feels human to Elara can sound evasive to Voss. An answer that sounds smart to Voss can sound scripted to Mara. The real game is learning what each judge thinks “human” means.

Play it here: https://imitation-game-tan.vercel.app

Why It Fits The Jam

June is Alan Turing’s birth month, and the challenge explicitly calls out the Turing Test as part of the June theme.

I wanted to make an ode to Turing that was not just decorative. So the whole game is built around the idea from his 1950 paper, Computing Machinery and Intelligence: if a judge only sees your answers, can they tell whether you are a person or a machine?

The twist is perspective. Most Turing Test stories put you in the judge’s chair. IMITATION puts you on the other side of the screen, trying to survive being interpreted.

How The Game Works

The game has:

21 questions total: 7 per judge

63 answer variants: 3 answer choices per question

Three hidden scoring dimensions: logic, emotion, and certainty

Three different judge formulas: each judge rewards and punishes those dimensions differently

A hidden trust score: good answers recover trust, bad answers drain it, and hitting zero means you are identified

The answer order is shuffled every time a question loads, so the player cannot simply memorize “A, then C, then B.” The questions stay in a fixed order so each judge still has a clear dramatic arc.

Best Ode To Alan Turing

This is the category the game most directly targets.

The mechanics are the tribute:

The player is trapped inside Turing’s Imitation Game.
Passing is not about being truly human. It is about becoming hard to classify.
Each judge represents a different argument around machine intelligence: feeling, reasoning, and self-awareness.
The ending returns to Turing directly, explaining the original question he asked in 1950 and why it still feels unresolved.

I also wanted the game to carry some of the sadness around Turing’s history without turning it into a lecture. The game is about performance, identity, suspicion, and the cost of being examined by people who already think they know what you are.

Best Google AI Usage: Antigravity App

I used the Antigravity app as the creative and implementation partner for this submission.

What Antigravity helped produce:

Core design direction: a Turing Test game played from the machine’s side.

Question bank: 21 questions split across three interrogators.

Answer variants: 63 total answer options with hidden logic, emotion, and certainty values.

Judge personalities: Elara, Voss, and Mara, each with different values and reaction styles.

Scoring review: balancing the formulas so no one strategy works for every judge.

Progressive visual distress: CRT scanlines and flicker increase as trust drops.

Responsive polish: Antigravity checked the deployed game and helped fix desktop, tablet, and mobile layout issues.

The game does not call Gemini or any AI API at runtime. It is a single client-side HTML file. Antigravity was used as the builder and design collaborator, which is the Google AI usage I am submitting for this category.

How I Built It

The whole game is one file:

index.html
Vanilla HTML
Vanilla CSS
Vanilla JavaScript
No framework
No build step
No runtime server

Under the hood, the game is a small state machine:

TITLE -> INTRO -> JUDGE_INTRO -> QUESTION -> REACTION -> ROUND_END -> WIN/LOSE

Enter fullscreen mode

Exit fullscreen mode

Each answer has three numeric scores:

logic: 0-10
emotion: 0-10
certainty: 0-10

Enter fullscreen mode

Exit fullscreen mode

Each judge reads those values differently. Elara punishes too much logic. Voss punishes too much emotional vagueness. Mara punishes certainty itself.

The CRT effect is pure CSS: scanlines, text glow, judge-specific color shifts, and flicker driven by the current trust level. The audio is generated with the Web Audio API, so there are no external sound files.

What I Like Most

My favorite part is that the game makes “passing” feel uncomfortable.

You are not proving you are human. You are learning what each person expects a human to sound like, then shaping yourself around that expectation. That felt like the right way to honor the Imitation Game: not as a trivia reference, but as a playable pressure system.

Links

Thanks for playing. If you reach the end, the final question is still Turing’s:

Can machines think, or are we only measuring what judges are willing to believe?



Source link

TECH & AI
CDK Deploy-Twice: When Your Infrastructure Needs to Know About Itself
jackminion 0



There is a moment that catches a lot of people out who are new to AWS CDK. You deploy a service, the deploy succeeds, and then you realize the service cannot fully configure itself because it did not know its own endpoint until after it was running.

This is not a CDK bug. It is a genuine chicken-and-egg problem, and once you understand it, the solution is straightforward-ish.

The problem

Some resources only exist after CloudFormation has provisioned them: ALB endpoints, service URLs, and auto-assigned DNS names. These values are not known at the cdk synth time. They are outputs that come back after the stack deploys.

If your application needs to know its own public URL (e.g., to build redirect links), well then, you are in a kerfuffle. You cannot pass a value into the stack that the stack itself has not produced yet. CloudFormation is not psychic, so unfortunately neither is CDK (I hear AI is working on this, though).

What it looks like in practice

Here is a real example from my latest YouTube tutorial video. This is a URL shortener that needs BASE_URL to construct the short links it returns, but BASE_URL is the service’s own endpoint, which CloudFormation only assigns after the ECS service and ALB are provisioned.

The CDK stack handles this with tryGetContext:

const baseUrl = this.node.tryGetContext(‘baseUrl’) as string | undefined;

const environment = (
{ name: ‘TABLE_NAME’, value: table.tableName },
{ name: ‘AWS_DEFAULT_REGION’, value: this.region },
);

if (baseUrl) {
environment.push({ name: ‘BASE_URL’, value: baseUrl });
}

Enter fullscreen mode

Exit fullscreen mode

And the endpoint is exported as a stack output:

new cdk.CfnOutput(this, ‘ServiceEndpoint’, {
value: service.attrEndpoint,
description: ‘Re-deploy with –context baseUrl= to wire BASE_URL’,
});

Enter fullscreen mode

Exit fullscreen mode

tryGetContext returns undefined if the value was not passed in, so deploy one works fine. It simply runs without BASE_URL set. Deploy two wires it in. Therefore, two deploys, one working service, zero existential crises.

The deploy pattern

Deploy 1: provision the infrastructure, get the endpoint:

cdk deploy EcsExpressStack

Enter fullscreen mode

Exit fullscreen mode

Deploy 2: pass the endpoint back in as context:

SERVICE_URL=$(aws cloudformation describe-stacks \
–stack-name EcsExpressStack \
–query “Stacks(0).Outputs(?OutputKey==’ServiceEndpoint’).OutputValue” \
–output text)

cdk deploy EcsExpressStack –context baseUrl=$SERVICE_URL

Enter fullscreen mode

Exit fullscreen mode

Why this is not a CDK bug

CDK synthesizes a CloudFormation template before anything is deployed. At synth time, late-bound values like ALB endpoints exist only as CloudFormation tokens, which are placeholders that resolve later. You can use them within the same stack (they resolve correctly in the template), but you cannot read them back into your TypeScript logic during synth. This is because the template has not run yet, and therefore the value does not exist yet. This is simply the correct order of operations.

tryGetContext sidesteps this. You supply the value externally on a subsequent deploy, once CloudFormation has resolved it.

When you will run into this

A service that builds URLs pointing to itself
A resource that needs its own ARN or DNS name as a config value
Cross-stack references where stack B’s input is stack A’s output and you have not wired them through CfnOutput and Fn.importValue

The pattern feels a little awkward the first time. It stops feeling awkward once you understand why it works that way. Then starts feeling awkward again when you dust off that old forgotten side project (you know, that one).

So which came first: the service or the endpoint?

The endpoint… but only after the service… which needed the endpoint to configure itself… which required the service to exist first.

At this point, I recommend not thinking about it too hard.



Source link