This page covers the first real North-America-market SWL discs this project had access to (RNS510_4366, US_RNS-510_SW1140), what they add beyond the EU discs the rest of this wiki is built on, and a complete crack of the Sirius TravelLink content database and its channel-art image format. See SWL Disc: Boot Chain and Build System for the shared disc/boot-chain format these build on. Reader/analysis code: research/swl_5238_reader.py, research/poi_db_reader.py.

UPDATE, a later session: the compiled firmware's own CODE side of this subsystem — real class/method names implementing this page's already-cracked SIRIUS.DB3 schema almost one-to-one (SportsScoresPersistData, FuelPricesPersistData, GraphicalWeatherPersistData/MDCacheWeatherShapes storm-tracking, ChannelArtPersistData) — found via a whole-file reloc-confirmed name scan of FHDD6.FLI. See Firmware Reloc-Confirmed Names for the full writeup; this page remains the authoritative source for the actual on-disc database/image formats.

Both confirmed real via the same Version.txt/BlScript.cfg format already known from the EU discs — no new container format, same disc family.

US_RNS-510_SW1140: #Steckbrief: C_NAR_9.442_t950 C3/C4C/C6, VwSwIndex 1140/1142, dated 2011-04-12, author RoNe (the same engineer already known from the EU discs' own USER.CFG). Real VW part numbers 3C0035684C/7L6035684D/3C0035684D/7L6035684E — a completely different prefix series from the EU discs' 1T00.../3T00... (3C=Passat B6/CC NAR, 7L6=Touareg NAR, by real VW part-number convention).

RNS510_4366: #Steckbrief: C_NAR_18.366_t1 C10/C12, VwSwIndex 4366, dated 2012-11-15, author MaGo — a NEW engineer initial, not among the ones already known from INFO/CDSTRUCTTMP.CFG's changelog (AKls/m./y./MaRu/AKr/RoNe). A later-generation NAR build than SW1140.

Both ship WA/NARRADIO.FLI/NARADIO6.FLI directly (previously only known by path reference in the EU disc's own INFO/INOUT.TXT manifest) plus real NAR region-coding scripts (NARPQTO.WSH, NARBY.WSH on RNS510_4366). RNS510_4366 additionally ships SIRIUS.DB3 (below), a real CH_ARTS.WSH/DEL_CA.WSH/DEL_CHAR.WSH trio (resolving the previously-unidentified "CH_ARTS" name from INOUT.TXT — "Channel ARTS", Sirius channel-art management, confirmed by the sibling CHARTS/ folder below) and DEL_SIR.WSH/MD_SIR.WSH.

The NAR coding scripts REFINE the SetCoding byte map already documented on HOST BSP and Vehicle Coding: SetCoding(0x400, 2, 7, 1), commented "SDARS/Sirius: Active for NAR", uses value 2, not the plain boolean 1 every other flag in that byte array uses — byte-offset 7 is a small ENUM, not a single bit, plausibly XM=1/Sirius=2 (the 2 satellite-radio providers that merged in 2008; RNS510 NAR units shipped with either depending on model year/trim), not independently confirmed further. Also: both NARPQTO.WSH/NARBY.WSH set "Testmode: NOT active" — the FIRST time this project has seen that register explicitly OFF (every EU region script found elsewhere leaves it active). Real, concrete evidence these NAR scripts are production-configuration coding, not factory-sample coding like the EU ones — and independent confirmation register 0x21 really is a genuine binary active/inactive toggle (both states now directly observed).

RNS510_4366\SIRIUS\SIRIUS.DB3 is a real, standard SQLite database (opens directly, no proprietary container — exactly like the map disc's own POI.DB3). 62 tables. The 2 largest — Poi_BaseAttributes/Poi_AddressAttributes/Poi_SiriusAttributes, all 158,088 rows each — share Poi_BaseAttributes's exact column shape from the map disc's POI.DB3 (Poi_ID/PoiPartition_ID/ Coordinate/Name), plus a Sirius-specific sibling table (SiriusPoiId/Poi_ID/Version/CategoryId/Constraint_A/ Constraint_B). Real, immediately recognizable content: "BLOXHAMS SHELL", "CHEVRON", "UNION 76", "FORTUNA CHEVRON" — real US gas-station brand POIs.

decode_coordinate() (already cracked against the map disc's POI.DB3, research/poi_db_reader.py) applies to this file completely UNCHANGED — no adaptation needed, tested directly against 15 real rows: every one decodes to lon≈-124, lat≈40-41, exactly Humboldt County/Eureka, Northern California (the real US-101 corridor) — immediately plausible for real "Union 76"/"Chevron"/ "Fortuna Chevron" station names, not a coincidental range match.

The real, concrete home of USER.CFG's own TRAVELLINK build flag (disabled on every EU disc): real Sirius TravelLink content-service tables exist in the schema — FuelPrice/FuelBrand/ FuelRegions/FuelType (fuel prices), WeatherMessages/ StormAttributes/StormWatchBoxes/SkiMessages (weather/ski conditions), Movies (showtimes), Sports/Teams/TeamStatus/ HeadToHeadSportTable/RankedSportEvent (live sports scores), Headlines (news) — all real, named, typed tables, though EMPTY on this specific disc (0 rows each; only the POI/fuel-station layer is populated, consistent with this being a factory SWL sample rather than a live subscriber unit's own downloaded content). DatabaseAttribute confirms real per-subsystem schema version stamps (schema/core= 001.0001, schema/poi=003.0000, schema/sirius=005.0000).

156 files, one per Sirius channel, in this specific 128X88/ folder (the folder name IS the pixel dimensions, confirmed exactly below). The header is almost entirely self-documenting plain ASCII:

DDBDDB          -- 6-byte magic
\x01            -- version = 1
B               -- 1 byte, role not decoded
__RGB555\x00    -- 8-byte pixel-format tag, NUL-terminated
\x80\x00        -- uint16 LE width  = 128
\x58\x00        -- uint16 LE height = 88
\x41            -- 1 byte, role not decoded
<zlib stream>   -- starts immediately after, real `78 da` header

Confirmed on 1.DDB: width/height fields read back exactly 128/88, matching the folder name exactly. The zlib stream's own decompressed size is always exactly width*height*3 (33,792 bytes for 128×88) — NOT width*height*2 as a naive reading of the RGB555 tag would predict. A first hypothesis (plain interleaved 3-byte-per-pixel RGB truecolor, ignoring the format tag) was tested and refuted by rendering it directly: pure scrambled noise.

The real layout is 2 SEPARATE planes, concatenated, not interleaved: a width*height*2-byte RGB555 color plane immediately followed by a width*height*1-byte plain 8-bit alpha/mask plane. 22,528 + 11,264 = 33,792, exact. Rendering the mask plane alone as grayscale shows a clean, coherent silhouette shape, confirming the plane-split before even getting the color channel order right.

Channel order is BGR555, not RGB555 despite the header's own literal tag — confirmed by rendering both orderings directly: RGB555 produces wrong, inverted-looking colors; BGR555 produces correct, natural colors. Visually confirmed on 3 real files, real Sirius channel names, fully legible with correct transparency: 1.DDB = "40s on 4" (a real 1940s-music Sirius channel) with an airplane-silhouette mask; 50.DDB = "WATERCOLORS" (clean cyan/magenta text on transparent background); 100.DDB = "SIRIUS XM Patriot" with an eagle icon.

The filename IS the real key, confirmed exactly against SIRIUS.DB3's own Sources table: <N>.DDB ↔ Sources.SourceId = N. 1.DDB = "40s on 4" matches Sources row (1, '40s on 4') exactly; 50.DDB's "WATERCOLORS" matches row (50, 'Watrclrs') (abbreviated in the DB, same channel); 100.DDB's "SIRIUS XM Patriot" matches row (100, 'Patriot') — 3 for 3, no ambiguity. Sources has 157 rows to this folder's 156 files (off by one — plausibly SourceId=0, "Preview", has no dedicated channel-art file; not chased further). This CHARTS/CHANNELARTSCACHE/ folder is a live, per-channel logo CACHE keyed directly by SourceId — separate from SIRIUS.DB3's own baked-in Image_BaseAttributes/ ImageBlob_BaseAttributes tables (most likely generic category icons by the map disc's own POI.DB3 icon-chain precedent, not independently verified).

The disc ships (at least) 3 real resolution variants, not just 128×88 — confirmed by the real CH_ARTS.WSH/DEL_CA.WSH flashing scripts, which reference 2 sibling folders on the disc this project hadn't opened directly: CHARTS/ChannelArtsCache/71x50/ and CHARTS/ChannelArtsCache/89x62/, alongside 128x88/. CH_ARTS.WSH is the real runtime install step — it mkdirs a matching folder tree on the unit's own hard disk, then xcopys each resolution folder straight off the mounted disc (/cddos/CHARTS/ChannelArtsCache/<res>) onto /hdb3/data/ChannelArtsCache/<res>; DEL_CA.WSH/DEL_CHAR.WSH are its real uninstall/cleanup counterparts. A genuine, dated engineering-history detail survives in DEL_CHAR.WSH's own real vendor comments: this live cache originally lived at /tffs0/data/ChannelArtsCache (the unit's internal flash) and was moved to /hdb3/data/... (the hard disk) on 2011-10-18, tracked under a real change request (CR 70793) — the 3 resolutions are plausibly for 3 different real on-screen tile sizes (channel list row icon / now-playing icon / a larger detail view), not independently confirmed further.

This is exactly the decoder the map viewer tool's own Sirius POI layer/channel icons use — see Map Viewer Tool.

In-Band On-Channel (HD Radio) firmware was searched for directly on both real NAR discs (the single most plausible place it would ship) — neither RNS510_4366 nor US_RNS-510_SW1140 contains an IBOC.FLI file or IBOC folder anywhere, checked with a recursive filename search, not just the top level. Both discs' own USER.CFG confirm why: IBOC = 0/FORCE_IBOC_UPDATE = 0, the same disabled state already found on the EU discs. Both discs' real EcuOrder.txt flash sequences (SWL → HOST → APPS → HDD → RADIO → [MPEG, NAR-disc-only] → VUCI) confirm this isn't an oversight — IBOC genuinely never appears as a flashed target. IBOC IS a real, known build option in the shared build-configuration system on every disc checked (CDSTRUCT.CFG/USER.CFG all reference it) — just never enabled on any of the 5 real discs this project has had. A genuinely different disc (built with IBOC=1) would be needed to actually open this file.

Each NAR disc's own FHDD6.FLI is a real, distinct build: RNS510_4366 = 87,890,828 bytes (~2.2MB LARGER than the EU disc); US_RNS-510_SW1140 = 75,554,712 bytes (~10MB smaller, an older 2011 build). Real "Sirius"/"SDARS"/"IBOC" debug strings appear in ALL 3 builds checked, including the EU one — shared, market-independent APPLICATION code gated at runtime by the SetCoding byte-7 enum above, not a separate per-market codebase.

A promising-looking lead, tested and REFUTED: RNS510_4366's own "Sirius"/"SDARS" strings cluster heavily at file offset 10-15MB — inside the exact zone Firmware Reversing already confirmed dead for the EU build, raising real hope a different market's build might have LIVE code there. Checked directly with find_prologues(): prologue density is 1000+/MB from 2-9MB, then ZERO from 10MB on — the identical shape already documented for EU. The 10-15MB strings are Java-class content, not native code. UPDATE, a later session: this Java-content region and its real boundaries are now precisely characterized, directly resolving most of the long-standing "9MB+ wall" mystery (readNodeMP0 and friends) — see Firmware Reversing's dedicated section.

The SAME FHDD6_LOAD_BASE (0xf688dcf4) resolves a real, sensible symbol table on this completely different-sized build — parse_symbol_table() finds 26,215 total entries (10,268 under 9MB) on RNS510_4366 — real, independent confirmation (a 4th distinct build family, not just 2 EU siblings) that this base is a genuine, stable toolchain property. readNodeMP0/findNode__14MDCacheTIRTree (this project's own highest-value unreachable targets) resolve to 10.9MB/16.4MB in this build too — squarely inside the confirmed-dead zone, same as every EU build. Closes "try a different market's firmware" as a real, tested avenue for the 9MB+ wall — confirmed structural across EU and NAR market families both, not an EU-specific stripping choice.

A quick follow-up: WA/CTEST.OUT is byte-IDENTICAL (same SHA256) across all 6 copies available at the time — 5238_MOD_C3_C4, 5274_MOD_C6_C12, 6276_MOD_C14, RNS510_4366, US_RNS-510_SW1140, and VIM_Berto89 (below) — including the 2006-dated VIM_Berto89 copy. This tool hasn't changed at the byte level across years of firmware releases and both market families.

A real but much OLDER and much SMALLER disc: #Steckbrief: C_EU_9.242_t560, VwSwIndex 1300/1302/1304, dated 2010-04-27, the SAME "This is an unofficial SWL CD by josi" community-repack disclaimer already known from the main EU disc — confirming a real, recurring repacker across multiple disc generations, not a one-off. Only 159KB total, missing every top-level ECU folder (APPS/HOST/ HDD/etc) — just BlScript.cfg/CRC.16/Dir.inf/EcuOrder.txt/ Version.txt + a WA/ folder holding CTEST.OUT (dated 2006-03-28 — an OLDER build than every other CTEST.OUT copy examined) and VIM.WSH — what "VIM" in the folder name actually refers to: a minimal, GENERIC coding script with only the universal register-level calls (SetRegDataHex(0x21,"01",...) testmode, SetRegDataHex (0x0B3A,"012C",...) speed-limit), zero SetCoding calls — confirming these 2 register-level settings really are vehicle/manufacturer- independent baseline setup, cleanly separate from the per-variant SetCoding calls every other region script carries. ("VIM" = Video In Motion — see the full confirmation and its later naming implications on SWL Disc: Boot Chain and Build System.)

Despite its promising name, a full recursive tree diff (344 files each side, every file hashed) against 5238_MOD_C3_C4 found ZERO differences anywhere — same file count, same relative paths, same SHA256 per file. Same exact VERSION.TXT identity in both. The "VIM-Testmode" label is just how this particular copy/download was named by whoever distributed it — plausibly describing what people USE this disc for (testmode/coding access via the WA scripts already documented elsewhere), not a distinct, separately-modified repack. Recorded so a future session doesn't re-diff this specific pair expecting a different result.

import sqlite3, zlib
conn = sqlite3.connect("SIRIUS.DB3")
# decode_coordinate() from research/poi_db_reader.py applies unchanged

with open("1.DDB", "rb") as f:
    data = f.read()
assert data[:6] == b"DDBDDB"
w, h = int.from_bytes(data[15:17], "little"), int.from_bytes(data[17:19], "little")
pixels = zlib.decompress(data[20:])   # width*height*3 bytes: RGB555 color plane + 8-bit mask plane

Full narrative and every validation number: research/ swl_5238_reader.py's own module docstring — search for "3 NEW discs", "SIRIUS.DB3 -- OPENED", "CHANNELARTSCACHE", "IBOC.FLI -- CHECKED directly", and "The 2 real North America FHDD6.FLI builds".