OrcSDR v0.5.0-beta.1 — Offline Maps, Guided Setup and New Ways to Explore RF

Release notes for M5Burner and GitHub. These notes describe changes since v0.4.0-beta.1. The owner approved proceeding with this beta without completing the expanded decoder-by-dongle gate. Untested combinations and the unresolved intermittent watchdog observation remain disclosed limitations; approval does not turn them into passing tests. Firmware packages are published separately from the source merge/tag after their build and package checks.

OrcSDR v0.5.0-beta.1 is a substantial update to the M5Stack Tab5 receiver experience. It brings the OrcMaps engine into the application, adds a guided first-time setup process, introduces downloadable offline maps, and expands the receiver with Dead Air, native SSTV reception, live ACARS reception and improved shortwave listening.

It also addresses problems that appear during real use: maps disappearing after changing dashboards, LoRa reception becoming constrained by retained memory, slow or confusing location saves, full-screen redraws, SD logging failures, and clock information that does not clearly explain whether FT8 timing is trustworthy.

The emphasis is on making OrcSDR easier to start, easier to understand and more dependable as you move between different kinds of reception. The Tab5 remains a receive-only device: receiving and decoding signals, reviewing information and replaying a saved audio clip do not add an RF transmitter or a contact-making function.

This is a beta release. Reception still depends on the attached dongle, a suitable antenna, signal conditions, correct mode settings and the capabilities of each decoder. The additions below should not be read as a claim that every decoder has been qualified on every receiver and antenna combination.

Highlights

• A guided startup wizard for network access, receiver location and offline maps, using OrcSDR's own colors, controls and branding.
• OrcMaps integration shared by the location picker, LoRa map, ADS-B map and FT8 world view.
• A downloadable worldwide regional map, available through OrcSDR's own signed catalog and hosted on GitHub Releases.
• Offline map operation after installation, with a compact world overview supplied by the complete firmware installation.
• Smoother map interaction, using a cached view that follows your finger while the detailed replacement is rendered.
• Improved LoRa memory handling, node history, map labels and transitions between LoRa and FT8.
• Dead Air, a new six-tab dashboard for measured receiver activity, event logging and audio evidence.
• Native full-color SSTV reception, progressive image display, automatic mode identification and SD image saving.
• Live ACARS reception, aircraft/message browsing and persistent local message archives.
• Shortwave USB/LSB listening, band-plan AUTO mode, a clarifier and corrected HF tuning behavior.
• FT8 timing improvements, including clearer clock status, wider acquisition when time is uncertain and additional clock-correction tools.
• More consistent screen updates and storage behavior, with focused fixes for redraws, memory allocation, file synchronization and recovery.

First-time setup: a complete starting point

A fresh installation now starts with an OrcSDR setup wizard rather than expecting the user to know which Settings pages to visit first.

The sequence is:

Welcome → Network → Receiver Location → Offline Maps → Complete

The wizard is designed as a self-contained process. Network and location choices are presented within setup, reducing the repeated jumps between the wizard and unrelated Settings pages. Text, navigation and touch controls have been revised for the Tab5's 1280 × 720 display and five-inch screen.

Welcome and navigation

The Welcome screen explains the main setup choices. Back, Skip and Quick Start paths let users move through the process without requiring every optional service to be available. Setup can also be run again from Settings → System.

An interrupted setup retains progress through its stored setup record. Cancelling or rerunning setup must not silently replace an existing receiver location with an uninitialized point. Existing users do not need to discard a working configuration simply to access the new setup flow.

Optional network connection

Wi-Fi is useful for map downloads, address lookup, network-based location estimates and time synchronization. It is not required to display a map that is already available locally.

Skipping network setup remains a valid choice. A user can set a location manually and use the installed world overview, then return later to connect and obtain a more detailed pack.

The catalog-check flow now requests network time automatically when the device has no established clock. It shows progress while doing so and continues the catalog check when time is ready. A timeout or lost connection produces an in-flow retry message rather than requiring the user to discover a separate clock-setting page.

That automatic step supports secure online catalog access. It is not a new requirement for displaying an embedded or installed map.

Reception is paused during setup

Setup temporarily pauses receiver operation and receiver audio. The screen explains that reception is paused, keeping the process clearer and reducing competition for resources while connecting to Wi-Fi, entering a location or choosing maps.

The dongle remains connected and radio settings are retained. Automatic or serial-triggered receiver starts are held while the setup pause is in force. Leaving setup restores reception only when it was active before setup began; a receiver that was stopped should remain stopped.

Fresh installation versus an application update

Fresh settings cause the wizard to run. An app-only update preserves existing settings and does not intentionally erase the SD card or its map packs.

The M5Burner installation path for this release uses fresh NVS settings, so users should expect to go through setup again when installing that complete package. This resets device preferences; it does not format the SD card. A map already present on the card can be discovered again after the installation.

The P4 application, its settings, SD files and the C6 coprocessor firmware are separate things. Updating or erasing the P4 does not itself update the C6. Any C6 firmware update remains a separate operation.

Receiver location: several simple ways to choose your point

The Receiver Location flow explains the available methods rather than assuming every user wants to type coordinates.

Users can choose:

• Network-based location, for a convenient approximate starting point when connected.
• Address lookup, when an internet connection is available.
• The map picker, to move the map to the desired point and save it.
• Direct latitude/longitude entry, for a known coordinate.

A network estimate can be approximate or affected by the network connection. The map picker and direct coordinates allow the user to choose the actual receiver point instead of treating an estimate as exact.

Saving a location stores a latitude/longitude coordinate. It does not require an attached GPS, and moving the map does not continuously rewrite the saved receiver point.

The location shown under the crosshair is a proposal until Use Location is pressed. That action now gives immediate Saving… feedback before the slower storage work completes. The Receiver Location page refreshes the coordinates and shows a saved-location label instead of continuing to say Not Set when a coordinate has been stored without a custom name.

The map-picker entry point is more prominent. Long map-pack identifiers are kept within their display area, and coordinate values are repainted after a successful selection. These changes make it easier to see that the chosen point was actually accepted.

The saved receiver location supplies a meaningful reference point for location-aware dashboards. It can center a local map and support distance or relative-position displays; it does not invent a position for a received station that has not transmitted one.

OrcMaps: one shared mapping system

OrcSDR now uses a reusable integration with OrcMaps instead of each supported dashboard managing a separate basemap implementation.

The shared layer handles the supported PMTiles sources, archive discovery, camera requests, rendering, labels and map-memory coordination. Dashboards add the information appropriate to their job: LoRa nodes, aircraft positions, receiver markers or decoded station grids.

This gives the application a consistent direction while allowing different map experiences. A location picker and LoRa map need interactive navigation. FT8 benefits from a stationary whole-world view. Those screens do not need identical controls or the same geographic scale.

A built-in world overview

The complete installation includes a compact firmware-provided world overview. It provides an offline starting point when the SD card is absent, no regional pack has been installed or Wi-Fi is unavailable.

The overview is intentionally modest. It is not a street atlas. It gives users geography for choosing a receiver location and for appropriate global displays without requiring a large download before the application can be used.

The world data is a separate firmware data component. Users updating with individual low-level flash files should retain or install the matching world component from the documented package, rather than assuming a bare application image supplies every data partition.

Worldwide regional detail

The first production download is World regional detail — zoom 0–8.

The archive is 543,380,195 bytes, approximately 543 MB in decimal units or 518 MiB in binary units. It is downloaded to the SD card, not loaded into RAM as one giant image.

This pack is intended for regional situational awareness: geography, water, boundaries and appropriate place/road detail where provided by the source and supported by the renderer. It is useful for understanding where receivers, nodes and aircraft are located. It is not advertised as worldwide street-by-street navigation, satellite imagery or an address-level routing database.

OrcSDR reads the needed map data for the requested view. Users do not need to create a separate copy of the world file for every dashboard. The application does not generate new higher-detail maps from the downloaded file; detail that is absent from the pack cannot be created by zooming further.

Clearer map selection

Local Maps now presents a scrollable list instead of making users step through one installed map per page. Map descriptions include useful information such as coverage, zoom range, size and availability.

Installed packs and catalog downloads are distinct views. Finding a pack in the online catalog does not mean it is already on the card, and discovering a pack on the SD card does not mean the device has downloaded it from the catalog.

An installed map can be selected for use without requiring a new download. The firmware world overview remains available as a fallback.

Legacy map compatibility

The older ORCMAP1 map data and OrcMaps PMTiles packs are different formats. This update does not rename or reinterpret an old regional index as a PMTiles archive.

Existing SD data is preserved. Legacy map entries are identified explicitly where encountered; unsupported legacy content is not silently treated as a valid OrcMaps pack. New map delivery is based on the shared OrcMaps path and worldwide catalog rather than requiring a developer's personal regional-map setup.

Downloading maps directly on the Tab5

Open Local Maps → Get Maps → Check Catalog, select a pack, then choose Download/Resume. During first-time setup, the same choices are available from the Offline Maps step.

OrcSDR's own catalog

The firmware uses OrcSDR's configured, signed map catalog, with initial hosting through GitHub Releases in the OrcMaps repository:

OrcMaps map downloads and releases

The production catalog has no scheduled expiration. It is no longer the earlier TEST-ONLY pilot catalog.

At preparation of this release, the production catalog offers one downloadable worldwide regional pack, in addition to the firmware-provided overview. More compatible packs can be added through later catalog revisions. Additional regional recipes are being prepared, but they are not advertised as available downloads until their archives and metadata have actually been built and published.

Progress, background use and resume

The downloader shows transfer progress and byte counts. Users can leave the download page and continue using the device rather than assuming the application must remain on that screen for the entire transfer.

The navigation button now says Back, replacing the misleading Cancel label. While a transfer is active, the page explains that going back to the device does not stop the download.

Stop Transfer is the explicit transfer control. It pauses the operation so it can be resumed. Download/Resume and Retry Last use the stored transfer state rather than requiring a fresh download from the beginning every time.

Resume checks the remote object's identity and the requested byte range before appending. If the remote response does not match the saved transfer, OrcSDR must not concatenate unrelated data into an installed map. A small amount of data after the last saved checkpoint may need to be downloaded again.

Home also has a compact map-operation status shortcut for returning to map activity. Leaving setup and leaving the download screen are navigation actions; they are not substitutes for pressing Stop Transfer.

A quick check at the end, rather than rereading the entire map

This release changes the installation policy to avoid the lengthy full-file scans used by earlier development builds.

After downloading, OrcSDR performs a quick saved-file check: expected size, a readable supported PMTiles header, valid bounded root-directory metadata and compatible declared coverage. It does not reread or hash the entire map payload before installation.

Catalog signatures, HTTPS transport checks, transfer identity checks and installation/recovery bookkeeping remain. The change removes the long archive scans; it does not remove all checks from the download path.

The tradeoff is explicit: same-size damage outside the inspected metadata may not be detected during installation. A completed quick check is not a claim that every tile has been cryptographically verified. Checksum files remain useful for users who prefer to verify an archive on their computer.

Historical installation times that included full-file verification are not a prediction for this new path. A new measured end-to-end device installation benchmark is still needed before publishing a speed claim for it.

Manual SD-card installation is still supported

Users who prefer to download a map on a computer can copy a compatible PMTiles archive and its matching manifest into the SD card's /orcmaps/ folder.

The manifest and archive must match. A PMTiles extension alone does not guarantee that an arbitrary archive uses the schema, compression, rendering profile or metadata expected by OrcSDR.

The manual instructions explain filenames and the required folder. Map attribution and source information remain associated with each pack. The download catalog is convenient, but it is not the only way to place a supported map on the device.

Smoother interaction and clearer map drawing

Map interaction has received repeated UI and rendering improvements:

• The location picker uses much more of the display, leaving a substantially larger map area.
• Text, instructions, attribution and buttons have been enlarged for the physical screen.
• The initial picker view starts closer than the earliest world view, and pan arrows supplement touch movement.
• A tap and a drag are distinguished before recentering, preventing the initial jump to the touch point.
• The last completed map remains visible while a replacement is prepared, instead of clearing to black on a pan or zoom request.
• A cached map preview moves with the gesture while the worker prepares the detailed new view.
• Exposed strips are updated without needlessly clearing the complete visible map.
• Per-dashboard label controls allow users to hide or show place labels where supported.
• Place labels are suppressed at very wide views and appear at more useful regional zoom levels.
• Shared engine improvements address polygon rings/holes, tile-edge clipping and drawing order.
• Renderer and cache changes reduce repeated work, while temporary data and persistent working state are placed in appropriate memory.

Cached movement and a completed detailed redraw are different stages. Dragging can follow a finger while the newly exposed area still takes time to fill. This release does not promise an instantaneous redraw or a universal two-second refill time under every receiver workload.

LoRa and Meshtastic: maps, history and reception fixes

More usable node maps

LoRa's map uses the shared OrcMaps integration. Node labels are larger and easier to read, with OrcSDR styling and placement constrained to the map region.

Clustered nodes no longer need to produce an unreadable stack of overlapping names. The selected node receives priority; other names are placed where space allows. Markers are retained even when a name cannot fit. Node details remain available through the node list.

The map supports smooth cached dragging and the relevant map controls. Repeated idle redraws and label-toggle redraws have been narrowed so a stationary map is not repeatedly cleared. Map colors and controls were physically checked on development hardware during this work.

A node needs usable position information to appear at a geographic point. Receiving text, telemetry or NODEINFO does not necessarily mean that a position was included. A saved receiver location provides the local reference point; it does not assign coordinates to every observed node.

Building a useful local history

LoRa packet history and device information are retained locally so the receiver can accumulate knowledge over time rather than losing everything on a dashboard change.

The history supports the information present in decoded packets, including sender identity, messages, telemetry, NODEINFO and positions when available. Saved device history is restored from the SD card. Storage changes improve synchronization of archive metadata so an open log is less likely to disappear from the usable history after a reboot.

CSV handling also receives spreadsheet-safety escaping for received text. Receiver data should remain data when a log is opened in another program.

Memory pressure no longer requires a routine reboot

A major problem investigated during this release was LoRa reception becoming constrained after other memory-heavy operations. The automatic decoder path could require an additional large capture-sized workspace, leaving insufficient usable PSRAM even though the device otherwise appeared to be running.

The automatic capture path now preprocesses the buffer it owns rather than requiring that extra full capture-sized allocation. Buffer ownership and manual replay remain distinct so a diagnostic replay is not silently modified in place.

The work also improves transitions between LoRa and FT8. Inactive LoRa capture buffers are reclaimed when FT8 needs map memory. Returning to LoRa releases outgoing FT8 map resources before allocating LoRa's large buffers. FT8 retries temporary map allocation failures rather than remaining without a map until a reboot.

Additional review corrections release a completed automatic capture when decoder startup resources are unavailable, while preserving manual captures and the existing wait for a busy decoder. A failed startup should not leave a completed slot permanently blocking later traffic.

Receiver-plan and recovery fixes

The update includes regional retune fixes, including the EU_868 return path after other views, detector/preamble improvements, and gain/clipping handling. Entering LoRa from another band should not quietly inherit an unsuitable fixed manual gain.

For reception, match the transmitter's region, preset, slot/frequency and other relevant settings. Antenna suitability matters: a working HF antenna is not a substitute for an appropriate LoRa-band antenna. Controlled exact-message checks were used during development, but this is not a claim that every preset has been qualified on every dongle.

ADS-B: a map that belongs in its dashboard

The ADS-B map now uses the shared OrcMaps path with a layout fitted to its available panel.

The work removes the old radar-style rings/crosshair overlay from the geographic basemap, improves the placement of map controls, and separates aircraft information from map geography more clearly.

Map zoom no longer briefly falls back to the earlier regional-map appearance before returning to the new renderer. The old renderer flash was physically reported and corrected during testing.

Receiver location gives ADS-B a sensible local reference and starting center. Zoom/range controls adjust the displayed coverage; the range is not a guarantee of the distance at which an antenna will receive aircraft.

Labels can be shown or hidden without making an older basemap appear during the transition. Aircraft position displays still depend on valid decoded position information; a map cannot supply a position that has not been established from the received data.

FT8 and FT4: clearer timing and a dependable world view

FT8 and FT4 reception were introduced in v0.4.0-beta.1. This update builds on that work rather than presenting them as entirely new decoders.

A proper shared world map

The Map tab uses OrcMaps geography in a stationary whole-world view appropriate to amateur station grids. The receiver marker and decoded station/grid positions use the same projection, with polar-cap limitations labelled rather than filled with misleading geography.

This view is not intended to behave like the interactive LoRa map. It does not add a street map, pan controls or aircraft-style local tracking to FT8.

Most importantly, the FT8 map does not require a set or synchronized clock to display. Accurate time matters to decoding and receive-slot alignment, not to drawing world geography. An explicit unset-clock map regression covers that distinction.

The earlier missing-world-map problem after using LoRa was a memory-ownership problem. It is addressed through automatic reclamation, bounded retry and correct cleanup ordering. Partial sprite allocation is also cleaned up before retrying, instead of retaining half of an unusable map frame.

Clock status that explains readiness

The FT8 clock display now distinguishes having a calendar time from having recent evidence that the clock is accurate enough for the decoder.

The status can describe synchronization, age, stale time, failure and lack of Wi-Fi, rather than presenting a clock as locked simply because the RTC contains a date. Stored synchronization information is checked before being restored after a restart.

Tapping Home's time/date area or FT8's displayed time/clock controls opens the existing Set Clock page. Users can inspect the time, change the UTC offset, save a manual correction or request Sync NTP. Opening that page does not itself change the clock.

NTP synchronization remains available when connected. While the decoder runs, the clock policy can request a refresh when the last trusted sync becomes old and retry a failed attempt with a delay rather than continuously restarting it.

Better acquisition when time is uncertain

When clock timing is uncertain, the FT8 receiver can use a wider time window around the nominal slot. This helps it acquire stations that would otherwise fall partly outside a receive buffer cut against an inaccurate local clock.

The wider search can delay a result while the extra trailing audio is collected. It is an acquisition aid, not a promise that any arbitrarily wrong clock can decode normally.

Timing evidence from multiple decoded stations can also support a bounded correction. The estimator requires enough stations and agreement across a window of slots; one isolated decode is not treated as proof of clock error. A recent trusted network sync takes precedence.

Clock changes invalidate stale timing evidence and queued corrections. Retunes, runtime stops, manual clock changes and failed RTC writes receive specific handling so a correction gathered under earlier conditions is not silently applied later.

WWV measurement tools

The FT8 tools include an on-device WWV tick-measurement path for the supported WWV frequencies, with explicit measurement, calibration, synchronization and stop commands.

This is a separate, advanced clock tool. It needs a suitable received signal, and calibration and synchronization have different purposes. Interrupted, stopped or timed-out measurements must not be applied as successful corrections.

Host tests and firmware builds cover this work. Successful end-to-end WWV clock setting on the final release hardware is not claimed by these notes.

Logging, screenshots and controls

FT8 CSV writes retain staged data until write, synchronization and close succeed. Retry handling uses a stable file position so a partially persisted batch is not simply appended a second time.

PNG screen capture over serial provides a way to inspect the display without writing a screenshot to SD and interrupting reception for the file transfer. Stream length and host-side collection were corrected in this workstream.

The gain panel also exposes RTL AGC on receivers that support it, separately from tuner automatic/manual gain. Unsupported controls should not be offered as if every dongle implements them.

Existing experimental JS8 work is not promoted here to complete protocol coverage. Its mode, frame and control limitations remain separate from the FT8/FT4 improvements above.

New dashboard: Dead Air

Dead Air is a new dashboard for observing and recording what the receiver actually measured. It brings RF activity, audio evidence and event review into a dedicated workflow.

Its six tabs are:

Each tab has a plain-language information popup. The dashboard uses bounded updates and off-screen/tile-based drawing to reduce repeated full-screen repainting.

Measured activity and clear state

Dead Air shows receiver level, baseline and threshold, and can record an RF-rise event when the configured detector establishes one. A generated sweep records its gaps, and the steady-channel detector is suspended while the receiver is hopping between channels.

Disconnected or unsettled receiver readings are invalidated. An absent measurement should not be presented as a convincing-looking live value. Measurements and interpretation are kept separate.

Receiver controls offer the available demodulation paths—NFM, WFM, AM, USB and LSB—with the associated filters. Leaving the dashboard restores Home's prior band label and demodulation state instead of leaving a generic browsing state behind.

A local evidence journal

Dead Air writes a versioned JSONL session journal under /orcsdr/dead_air/ on the SD card. Event data is queued and written in bounded background batches. An event is counted as saved only after its write is flushed successfully.

This gives users a record they can inspect later rather than relying only on what was momentarily visible on the display. Recording failures are exposed rather than silently counted as saved evidence.

Receiver clips and optional microphone clips

Event-linked receiver clips preserve a short period of demodulated audio before and after an event. Available clips can be selected and replayed from Review, and the dashboard can verify a recorded clip against its stored checksum.

Microphone recording is separate, explicit and off by default. It has its own visible indication and separate files, so microphone evidence is not confused with audio received through the SDR.

This release also addresses a microphone-input problem after replay that could produce constant-value silence. The input is restarted, and such clips are rejected rather than saved as convincing evidence.

Dead Air limits

Environment pages do not create sensor readings when the required hardware is absent. Final hardware qualification of every detector condition and optional sensor remains separate from the implemented dashboard and host tests.

The journal shares the SD card with the rest of OrcSDR. Removing a mounted card during recording is not treated as a seamless hot-remount feature. A failed session must be reported, and a reboot may be needed before recording on a reinserted card.

Native SSTV: receive, watch and save color images

The new SSTV work brings a progressive, full-color receiver to the Tab5 instead of requiring an external computer to turn received audio into an image.

The receiver can display rows as they decode, retain completed or interrupted images in a small gallery, and save images to the SD card through the archive worker.

Automatic identification with honest confidence

A valid VIS header identifies a supported mode. When a header was missed, Auto mode can use repeated line-sync evidence to choose a provisional mode and start recovering the available portion of the image.

A sync-only start is labelled as partial/provisional rather than being presented as a complete VIS-confirmed reception. Unknown top rows are not invented. A subsequent valid VIS header takes precedence over an earlier speculative choice.

The application returns to listening for the next image after a reception finishes, without requiring a manual receiver restart for each transmission.

Supported image-mode families

The implemented full-color mode set contains 14 modes across Robot, Martin, Scottie and PD families. It includes familiar modes such as Robot36, PD120 and Scottie S1.

The full mode set has host-level image and timing coverage. Hardware acceptance is narrower: documented conducted-RF Robot36 reception on a Tab5 is not proof that all 14 modes have been received on every supported dongle.

Manual mode selection acts as a filter for the selected supported VIS mode. It is not advertised as forcing an arbitrary headerless waveform into a complete image.

Tuning, storage and recovery

SSTV adds its tuning workflow, automatic VIS/sync acquisition, weak-signal improvements, archive controls and read-only web export. Complete and useful partial receptions can be saved, with enough status to understand why an image ended.

The SD path uses cache-aligned buffering and a background archive worker. This addresses cases in which saving a large image stalled navigation or made storage unnecessarily slow.

Gallery and archive ownership protect an image while a write is pending. A full card, failed write or missing card is reported instead of silently claiming that the picture was saved. Unknown free-space information is no longer automatically reported as a confirmed full card.

Live ACARS reception and a persistent aircraft-message log

The ACARS dashboard is connected to the receiver and native decoder. It is not just a set of demonstration screens.

The dashboard provides live messages, message details, aircraft grouping, channel selection, activity information, an archive view and setup controls. CRC-verified blocks and repaired-frame markings are presented according to the information actually established by the decoder.

Message details include the available ACARS fields and raw message content. Aircraft can be grouped by the received tail identifier, making it easier to follow activity over time instead of reading an unrelated stream of individual rows.

Channel presets and custom-frequency requests support listening in the appropriate band. They are starting points, not a guarantee that a particular airline or local channel is active.

SD archive

Verified received blocks can be written to a local JSONL archive under /orcsdr/acars/. With a valid clock, dated files are used; an undated path allows logging without inventing a valid timestamp when time is unset.

Saved message content retains an exact representation alongside a printable preview, and recent archive history is loaded into a bounded browsable store. The application does not need to hold the entire lifetime log in memory to show useful recent history.

This is a received-message archive, not automatic aircraft-position tracking. ACARS text alone does not establish every aircraft's location, nor does this update promise multi-channel monitoring, arbitrary application-message interpretation or automatic ADS-B correlation.

Shortwave Explorer and Home HF listening

Shortwave Explorer now supports actual AM, USB and LSB listening, with an AUTO choice that follows the implemented band plan.

For suitable amateur voice segments, AUTO selects the appropriate sideband; broadcast and other AM areas retain AM behavior. The mode in use is reflected in the display, frequency status and supported saved-memory/log records.

The sideband path has a dedicated voice filter and a clarifier. The clarifier changes in 50 Hz steps within its bounded range, helping bring voice pitch into place without pretending the AM filter controls adjust the fixed SSB passband.

Direct-sampling inversion handling is limited to the applicable receiver route and frequency range. The correction is not blindly applied to a normal tuner path. Small dial changes also account for the difference between the displayed dial and the receiver's quantized local-oscillator center.

Home's frequency keypad and OrcDial frequency entry now follow what the attached dongle can tune, rather than imposing the earlier fixed VHF/UHF-only entry range. Supported HF frequencies open in the Shortwave context so the HF mode behavior applies.

This does not make an HF-incapable dongle receive below its hardware limits. Receiver capability and antenna suitability still decide what can actually be heard.

Speaker-volume handling uses the fuller supported range on the affected non-P25 paths, and sideband gain was adjusted as part of this listening work. Users should still choose a comfortable listening level for the connected device and signal.

Home, navigation and display improvements

Home plot cadence has been revised toward approximately 33 ms updates, instead of the older slower refresh throttling in the affected paths. That is a scheduling target, not a guarantee of a fixed 30 frames per second under every receiver, storage and map workload.

The update addresses overlapping Home/RF Lab content and other screen-ownership problems. A screen transition should establish the new owner rather than leaving the previous dashboard visible behind live content.

Repeatedly opening Settings no longer loses the original graphics-enabled state. That fixes a case where audio and tuning remained functional while Home's spectrum and waterfall stopped drawing after navigation.

Ordinary progress, value and animation updates have been separated from full-page layout changes in the affected screens. Static controls and the last valid map are retained wherever possible instead of clearing the entire display for every revision.

Fresh installations also use the revised default display orientation, rotated 180 degrees from the earlier default. Existing app-only installations retain their saved orientation.

Shared memory and SD reliability work

Large-map rendering, FFT/decoder workspaces, capture buffers, logs and companion connections all share a small embedded system. This release treats retained memory and storage ownership as application behavior rather than assuming free RAM at boot guarantees enough RAM later.

Changes include:

• Moving suitable cold state, metadata and working buffers to PSRAM while preserving the internal/DMA reserve needed by hardware services.
• Reclaiming inactive feature buffers through a shared mechanism that lets each holder protect live work.
• Avoiding the extra capture-sized LoRa preprocessing allocation on the automatic path.
• Retrying FT8 map allocations after temporary pressure and freeing incomplete sprite pairs.
• Using actual filesystem free-space queries rather than raw card size as a download/write preflight.
• Distinguishing a failed capacity query from a confirmed lack of space where corrected.
• Guarding SD DMA buffer reachability and using the shared cache-aligned write approach.
• Keeping FT8 staged rows until file synchronization/close succeeds and retrying at the correct file position.
• Improving LoRa archive synchronization and shared storage regressions.

These changes reduce several known failures, but they are not a claim of unlimited memory or an SD hot-removal/remount feature. Slow, full, damaged or disconnected media can still cause an operation to fail, and the application needs to report that failure accurately.

OrcDial and coprocessor considerations

OrcDial remains optional. Touch controls remain the primary standalone interface; the Tab5 does not require a companion to complete setup, select a map or receive supported signals.

Companion work in this update reduces unnecessary boot-time internal-memory use, starts the bridge on demand when appropriate, and improves reclaim/placement for connection resources. Pairing and connection errors remain explicit instead of being hidden by a generic success state.

The Tab5's P4 application and C6 firmware have separate versions. A device can need a compatible C6 version for particular companion features even while its basic receiver and map functions work. Follow the applicable C6 update instructions rather than assuming a P4 reinstall has already upgraded the coprocessor.

Serial control and observability

New and changed user actions continue to receive named serial control where implemented. Maps and setup expose commands for listing packs, opening the picker, moving the camera, saving a location, changing labels, checking the catalog and controlling downloads.

RTL_UI OPEN CLOCK opens the same Set Clock page as the touch shortcut. FT8 retains its existing status and diagnostic controls, and Dead Air has named status and session/testing controls.

Status output distinguishes readiness, pending work and completion. Sensitive saved coordinates in the affected map-status paths require authentication; basic readiness remains available without exposing the saved point.

This is an expansion of observable control, not a claim that every historical control in the entire application has completed a serial-parity audit. State-changing commands continue to use the existing authenticated session.

Compatibility, installation and existing data

• Use the release's matching Tab5 firmware/package and follow the documented installation path.
• A fresh settings installation opens setup. An app-only update preserves device preferences.
• The M5Burner fresh-settings package does not format the SD card.
• Existing SD histories, images and map packs are not intentionally erased by an app-only update.
• Old ORCMAP1 data is not automatically converted into a PMTiles pack.
• The complete firmware world overview and the larger SD regional pack serve different purposes; the SD download is optional for basic overview use.
• Map archives need a matching, compatible manifest and rendering profile. An arbitrary online map API or arbitrary PMTiles file is not automatically supported.
• The integrated RTL-SDR driver remains on the established 0.9.3 line; this update does not advertise a new driver version as the source of the map improvements.
• Receiver support must be understood per model and function. Blog V4, V3c, V4L and Nooelec NESDR SMArt V5 do not have identical hardware paths or tuning capabilities.

Beta limitations and validation boundaries

The release work includes host regressions, fault-injection tests, ESP32-P4 compile/build checks, two-Tab5 installation work and physical UI acceptance for selected features. Those are different forms of evidence and should not be combined into an unsupported promise that every mode is fully qualified everywhere.

Important limits remain:

• An intermittent unexpected restart was observed around a dongle disconnect and navigation. A later controlled disconnect/navigation test recovered without a reset, but the original watchdog cause remains unresolved. The retained crash dump was stale and did not supply a current backtrace.

• Conducted Robot36, PD120 and Scottie S1 receptions completed, saved to SD and passed reference-image checks on Blog V4, V3c, V4L and Nooelec V5. Source-DMA-interrupted attempts were excluded. This does not qualify every decoder, HF path or physical audio/control combination.

• Fine map-detail refill can lag behind the cached moving preview. Current drag responsiveness was accepted during development; a universal refill-time guarantee is not claimed.

• Moving a map and generating newly exposed detail can briefly drop some incoming IQ data, so a packet or audio fragment may be missed during that interaction. This is an accepted limitation for this beta, not a claim of uninterrupted reception during map redraws. Idle reception and normal stationary use remain separate validation requirements.

• The expanded decoder-by-dongle release matrix is not complete merely because a map rendered or one controlled LoRa packet decoded.

• The automatic unset-clock catalog path has focused host and compile coverage; a final fresh-clock hardware acceptance remains separate from catalog access on a device whose clock was set manually.

• The new quick-file-check policy deliberately does not provide a full archive-payload hash guarantee. Its real-device installation-time improvement remains to be measured.

• SSTV mode coverage on the host is broader than the recorded conducted-RF mode/dongle coverage.

• WWV measurement/correction and optional Dead Air environmental hardware have their own remaining hardware acceptance limits.

• Existing experimental JS8 limitations are not removed by the FT8/FT4 timing changes.

• Recent review corrections must be included in the final tested release artifact; testing an earlier development image does not qualify a later binary automatically.

Map data and credits

OrcSDR uses the OrcMaps engine and compatible PMTiles archives for the new map path. The worldwide regional data carries its Protomaps/OpenStreetMap provenance and applicable attribution, including OpenStreetMap contributors. The compact world overview uses Natural Earth data.

Pack manifests preserve attribution and source information. Displayed map credit is part of the map experience, not disposable decoration. Third-party data licenses and the application's own licenses continue to apply.

For users upgrading from v0.4.0-beta.1

The most visible differences should be immediate: a more complete first-time setup flow, a much more useful offline map system, a clearer location workflow, additional receiver dashboards and fewer reasons to restart simply to recover graphics or memory after navigation.

For an existing device, begin by confirming the saved receiver location, opening Local Maps to see what is installed, and checking the production catalog if the worldwide regional pack is wanted. Select a suitable antenna before comparing reception between modes. A node or aircraft with no established position will not acquire one just because the basemap is more detailed.

For a fresh M5Burner installation, work through setup and choose the network/location/map options that fit the device's use. Downloading a regional map is a one-time preparation step for offline use, not a requirement to keep Wi-Fi connected whenever a map is displayed.

The intended result is a Tab5 that is easier to bring into service and more useful across a full session of receiving, exploring, saving and reviewing RF activity.

Previous release: OrcSDR v0.4.0-beta.1

Map packs: OrcMaps releases

Project: OrcSDR on GitHub