デスクトップ学院 規格部

デスクトップ学院トップページへ戻る

技術を語るうえで欠かせないのが、「規格（スタンダード）」という考え方です。規格を基盤として技術が積み重なり、現代社会のあらゆる仕組みが成り立っています。

DCCについて学ぶ際にも、NMRA DCC規格を理解しておくことはとても重要です。

生徒の皆さんは、このページを通じて NMRA DCC規格をしっかり理解し、学んだ内容を実際の作業や日々の模型ライフに役立ててください。

1. NMRA DCC規格とは

1.1 DCCの概要と目的

DCC（Digital Command Control）は、NMRA（全米鉄道模型協会）が策定した規格で、同じ線路上で複数の車両を独立制御するためのデジタル制御方式です。従来のアナログ方式では線路電圧＝速度だったため複数列車を独立に動かせませんでしたが、DCCでは 電力（常時電圧）＋デジタル信号 を同一レールで送ることでこの問題を解決しています。

DCC規格は、NMRAの中にあるDCC WG(ワーキンググループ)が策定を行っています。DCCメーカーの技術者やDCC技術に精通したメンバーが加わっている他、欧州の地域規格団体であるRail Communityの規格ともリエゾン関係にあります。

1.2 規格体系

以下に、主なNMRA DCC規格を示します。これ以外にも多数の規格が定義されており、DCCという技術を根幹から支えています。詳細は、NMRAのホームページを参照してください。いつでも、誰でも、自由に、無償で規格書をダウンロードできます。

1.3 歴史と発展

DCCは、ドイツの Lenz（レンツ）社が開発したデジタル制御技術をベースにしています。1980年代後半から1990年代にかけて、鉄道模型の複数列車制御をデジタル化する試みが進み、Lenz社は通信原理・デコーダ構造を構築しました。
その後、全米鉄道模型協会（NMRA）が Lenz の技術を基に 国際的な共通規格として標準化 を開始し、現在まで維持・拡張されています

鉄道模型デジタル制御の主流は1つではなく、代表的な競合として：

メルクリン（Märklin）社の Motorola フォーマットと、メルクリンの後継 mfx フォーマット

が存在し、ヨーロッパ市場を中心に普及しています。特にメルクリンは三線式の独自システムで動作するため、DCCとは根本的に異なる物理構造（３線式・センターシュー方式）があります。

なお、特にヨーロッパのDCCデコーダは、メルクリンとDCCの両方をサポートしたハイブリッドである場合が多いです。アジア・米国のメーカーのDCCデコーダは、DCCのみサポートすることが一般的です。

2. DCCの電気的な仕組み（S‑9.1）

2.1 電力と通信の同時伝送

DCCではレールを用いて電力とデジタル通信を同時に送信します。レール上の交流波形を数k-10kHz程度の高速で反転を繰り返すことでデジタル信号を実現します。

2.2 デジタル信号の生成方法

DCC信号は「レール極性の反転」がそのままビットを表します。アナログ電圧とは異なり、一定の振幅を持つ矩形波で構成されます。

2.3 出力電圧規格

DCC信号は、以下の通り、電圧の範囲が決められています。

最大電圧：22V
最小電圧：7V

実際にはスケール・ゲージによって、標準的に使われる電圧があります。たとえば、HOクラスで通常15V前後が多く使われます。Nゲージでは12Vから15Vの間くらいで使われることもあります。

なぜスケール・ゲージによって使用される電圧が異なるかと言うと、車両のモータや車内の電気的特性の影響を受けるためです。日本のNゲージは12Vで使われることが多く、モータの設計が12Vに最適化されている場合があります。過度に高い電圧を使用すると、モータの寿命を縮めることにつながります。

2.4 “1” と “0” のパルス幅

DCCではビット値をパルスの長さで表現します。

“1”：短いパルス（＋－周期＝約58µs）
“0”：長いパルス（95〜9900µs）

2.5 パルスの役割

パルスは、電子回路で非常に生成しやすい信号形式です。DCCを含め、デジタル鉄道模型では多く採用されています。デコーダに命令がない場合もコマンドステーションは常に同じ信号を繰り返し出力しており、電力供給や離線した場合の復帰処理にもなっています。

3. DCC通信方式の基礎（S‑9.2）

3.1 シリアル通信

DCCは1ビットずつレールに出力されるシリアル通信です。

3.2 デコーダはパケットを常時監視

レール上には多数のデコーダが接続されていますが、それぞれはすべてのパケットを読み取り、自分宛（アドレス一致）のものだけを処理します。

一致しないパケットは全て破棄されます。また、受信したパケットを処理している間は、受信をしないデコーダもいます。

3.3 1対N通信の特徴

DCCはスマートフォンの基地局通信のように、一つの送信源（コマンドステーション）から多数の受信器（デコーダ）へ配信されるブロードキャスト型通信です。

複数のコマンドステーションから、同じ経路を使ってパケットが送信されることはありません。複数のコマンドステーションを併用して使う場合は、経路を完全に分離し、同一線路上の場合には途中にギャップを置くなどして、電力系統を実際の電車のように分ける必要があります。

4. パルスとビットの詳細

4.1 “1”ビットの仕様

+電圧期間 ≒ 58µs
-電圧期間 ≒ 58µs
（許容誤差 ±3µs）

1周期116us(約8.6kHz)の矩形波が、”1″を示す信号となります。

4.2 “0”ビットの仕様

+電圧>=100us
−電圧>=100us

1周期200us以上の矩形波が、”0″を示す信号になります。最大10msまで許容されますが、通信としての帯域・データ送信効率が落ちるため、通常は100~110usあたりを出力するコマンドステーションがほとんどです。

なお、この特性を利用して、わざと長いパルスを送ることでアナログ車両走行を無理やり行う方式(Zero Stretching)がありますが、経験上、利用は推奨しません。

4.3 通信速度への影響

“0”が長いほど伝送速度は低下しますが、DCCでは主に“1”で連続送信する事が多いため、通常運転時の遅延は最小限に抑えられています。それよりも、Zero Stretchingや後述するRailCom等の伝送周期等の影響の方が大きいかもしれません。

5. DCCパケット構造（標準フレーム）

DCCパケットはレール上のデータ単位で、以下の要素で構成されます。

5.1 パケット構成

プリアンブル（“1”×12以上）
パケット開始ビット（0）
アドレスデータバイト
データバイト開始ビット（0）
命令データバイト（速度・方向など）
データバイト開始ビット（0）
エラー検出データバイト（XOR）
終了ビット（1）

5.2 プリアンブル

最低12個の“1”
14個以上送るのが推奨

5.3 アドレスデータバイト

7bitのアドレス（0AAAAAAA）
一部は予約値（0x00, 0xFE, 0xFFは特殊用途）

5.4 命令データバイト

例：速度・方向パケット（01DCSSSS）

D = 方向（1=前進 / 0=後進）
C = 拡張速度ビットまたはヘッドライト（後方互換）
SSSS = 速度4ビット

5.5 エラー検出データバイト

アドレス＋命令の全バイトのXORをとったものがエラー検出データバイトです。不一致ならパケットは破棄されます。かなり単純なエラー検出方式のため、バグや回路の異常等によって大量のエラーが発生した場合には誤受信する場合もあります。

6. 拡張パケット（RP‑9.2.1）

6.1 拡張パケットが必要な理由

標準パケット（基本）は、DCCの策定初期(1990年代)に定義された仕様となっており、2020年代の現代では陳腐化してしまっています。よって、このままでは、DCCの機能が大きく制限・限定されてしまいます。そこで、以下の目的の実現のために、拡張パケットが追加で定義されています。

・ロングアドレス（大量の車両への対応）
・28/128速度ステップ（滑らかな速度変化）
・多数のファンクション（デコーダの高機能化）

6.2 ロングアドレス

2バイトのサイズで1-10239(9999)の数値範囲のアドレスを持つ方式。
ショートアドレス( 米国式1-127 または 欧州式1-99)ではアドレスが不足する場合に利用する。

6.3 ファンクション拡張

ライト・音響等、豊富なファンクションを制御可能にするための拡張機能。拡張が進んでおり、F28より高いファンクション番号も定義されている。

6.4 Advanced / Extended Packets

標準パケットよりも長いデータ長を持ち、機能を拡張しています。

標準パケットとの違い（基本構造の比較）

✔ 基本パケット（S‑9.2 の最小構成）

アドレス（1バイト）
命令（1バイト）
チェック（1バイト）

固定3バイト構造。
シンプルだが、表現できる命令は限定的。

✔ 拡張パケット（RP‑9.2.1）

アドレス（1〜2バイト）
命令（複数バイト可）
チェック（最後に1バイト）

可変長構造で“複数バイトの命令セット”を扱える。拡張パケットでは命令バイトの最上位ビットや識別ビットを用いて、「拡張命令であること」を判別する仕組みが使われます。

基本構成

プリアンブル（“1”×12以上）
パケット開始ビット（0）
アドレスデータバイト1
アドレスデータ中間識別ビット（0）
アドレスデータバイト2
データバイト開始ビット（0）
命令データバイト（速度・方向など）
データバイト開始ビット（0）
命令データバイト（追加データ）※追加データがあれば繰り返す
データバイト開始ビット（0）※追加データがあれば繰り返す
エラー検出データバイト（XOR）
終了ビット（1）

特徴

✔ 1. アドレス部が可変（1バイト or 2バイト）
ロングアドレス時は 2 バイト使用。
✔ 2. 命令バイトが複数存在
ファンクションや速度、特殊動作展開に利用。
✔ 3. チェックバイトは“全バイト XOR”で算出
基本パケットと同じ方式。

アドレス領域：1〜10239（14ビット）

2 バイトを使い、以下の構造を持つ拡張パケットを送信します：

Address byte (110abcde)   先頭2bitが“11”で長アドレスを示す
Address byte 2 (xxxxxxx)
... instruction bytes ...

• 長アドレスを示すため、アドレスの最初の 2bit が “11” に設定。
• これによりデコーダは「これは2バイトアドレス」の判断ができる。

※ 注意：ショートとロングの境界値はNMRAで固定されていないため混乱の元。（前回話題になった点）

128ステップ速度制御パケット

命令バイトが拡張され、速度を 0〜127（実値1〜126）で表現できる。
Instruction: 0011 C VVVVVVV

C：方向ビット
VVVVVVV：7bit の速度

速度の細かな制御（特にサウンドデコーダの同期等）に必須。

拡張ファンクション（F0〜F28およびF29～F68）パケット
基本パケットでは F0〜F4 または F5〜F8 程度しか扱えません。
拡張パケットでは以下のような“ファンクショングループ”命令が追加されます。なお、2020年代以前はF28までしか定義されていなかったため、多くのコマンドステーションはF28までしか対応していない事が多いです。

これらはすべて 命令バイトを複数使うことで実現されます。

例：F9〜F12 の制御
Instruction 1: 1011DCBA
（A＝F9, B＝F10, C＝F11, D＝F12）

7. CV（Configuration Variables）

7.1 CVとは

デコーダの設定値を保存する不揮発メモリ領域（電源が切れても保持されるという意味）で、アドレス、加速度、減速度、ライト制御の設定・調整用のパラメータなどを定義します。さまざまな機能の設定値を格納しておくことで、多彩な動作や追加機能を実現できます。

しかし CV は柔軟性が高い反面、メーカーごとに実装方法の差が大きく、同じ機能でも CV 番号や値のルールが異なる場合があります。そのため、設定時には必ずデコーダ付属の説明書を確認することが重要です。

7.2 CVの分類

CVのパラメータは、「CV値」と呼ばれ、CV1からCV1024まで、デコーダによって定義がされています。その中で、NMRA DCC規格によって、予め全メーカーが共通して定義するべき番号・メーカー独自に決めてよ番号等を以下の３種類の分類で定義しています。

Mandatory（必須）：すべてのデコーダが実装
Recommended（推奨）：多くのデコーダが実装
Optional（任意）：メーカー独自の判断で実装するか判断して使用。基本的に互換性が無いケースが多い。

CVには３つのモードがあります。現在は、Directモードが多く採用されています。また、サウンドデコーダの音量や運転特性の微調整のために、運転中のCV書き込みモードであるOPSもよく使用されます。

7.3 CVの代表例

CV1：基本アドレス
CV29：基本設定（アドレス長、方向、速度ステップなど）
CV2/5/6：速度テーブル
CV49〜：ファンクション動作設定

7.4 サービスモード（S‑9.2.3）

プログラミングトラックを用い、デコーダに戻り信号を読ませて設定を変更する方式。

7.5 CV読み書きパケット

“読み書き専用の特殊パケット”が定義されており、コマンドステーションがデコーダから応答を得るための仕組みが用意されています。

■ CV の書き込みについて

CV 書き込みは、原則として「書き込み対象の車両だけを線路に載せて」行います。
ただし OPS モードの場合は、他の車両が線路上にあっても書き込み可能です。

書き込み動作は以下の手順で行われます。

1. コマンドステーションのプログラミング用出力端子に繋ぎ変える（一部のコマンドステーションは、通常出力端子と兼用の場合がある）
2. デコーダに対して、コマンドステーションからリセットコマンドを送信する
3. CV 書き込み専用コマンドを複数回、送信する
4. デコーダが書き込み成功を示すため、一瞬だけ電流を流す（CV Acknowledge）
   • この際、車両が一瞬「ピクッ」と動くことがあります

デコーダの組み込み方によっては、この Acknowledge 用の電流が十分に流れず、コマンドステーションが「書き込み失敗」と判断することがあります。

■ CV の読み込みについて

CV 読み込みは、書き込みに近い手順で実行されます。CV読み込みの違いとしては、Acknowledge 時の電流が大きいか小さいかを複数回チェックし、その結果から値を判断します。

モードごとの読み込み回数と速度は以下の通りです。

• Paged モード
  • 最大 256 回のチェックを行うため、読み取りに非常に時間がかかる
• Direct モード
  • ビット単位で読み取るため、8～16 回程度で終了し短時間で完了する

読み込み中は車両が連続して「ビクビク」と微動することがありますが、これは故障ではなく正常な CV 読み出し動作です。

■ CV Acknowledge と電流の条件

DCC 規格では、CV Acknowledge の際に 60mA 以上の電流を流すことが求められています。
しかし、以下のような場合には 60mA を流せず、読み込みに失敗することがあります。

• デコーダにモータが接続されていない
• デコーダの構造上、電流を十分に流せない
• 集電不良
• 複数台のデコーダや車両が置かれている
• 別に電流を消費する何かが繋がっている（室内灯など）

8. DCCシステム全体の動作例

8.1 動作フロー

コマンドステーションが運転指令をパケット化
ブースタを通してレールへ送信
全デコーダが受信
アドレス一致のデコーダが内容を解析
モータ・ファンクションを制御

8.2 モータ制御

速度命令パケットを解析し、PWMやモータドライバで回転数を制御。

8.3 アクセサリデコーダ

ポイント切替や信号機、ターンテーブルなどを担当します。
車両デコーダとは異なる命令形式を解釈します。

9. 互換性と実装上の注意

9.1 NMRA互換性のポイント

パルス幅と電圧を規格どおりにパケット形式（特に基本パケット）を厳密に、CVの読み出し・書き込み・共通仕様の実装が求められる。

１から実装するよりも、NMRA DCC WGが配布しているソフトウェアライブラリ等を活用すると、互換性の高い機器が実装しやすい。

9.2 メーカーの仕様差

OptionalなCVやファンクションは独自拡張があり、製品ごとに動作が異なる場合がある。

DCC信号の受信などでは、あまり大きな差は無いが、NMRA DCC規格には定義されていない実装・挙動部分で差異が出てくることが多い。CV読み書き等は、特にメーカー間で相性が出ることもある。

9.3 電気的実装差

パルス幅の精度、ジッタや電圧差、電圧の最大値により互換性問題が生じることも。特に、デコーダのコストにも影響してくるため、一部メーカーでは許容電圧が低い場合があります。

また、超小型のデコーダでは、設計上の都合で省かれた部品が悪影響し、一定条件で動作不良を起こす例もあります。

RailComといった、古いデコーダが対応していない技術を併用する場合、ノッキングや不動などの誤作動を起こす場合があります。

9.4 認証の取得

製造者IDを取得するには、最初にリリースする製品の試作品を用いて、NMRA DCCのコンフォーマンステストを受験し、合格する必要がある。

注：たまに相談を受けますが、デスクトップステーションでは、競合企業のための認証支援業務などは一切行っていません。自己責任・自社の力で、ID取得に臨んでください。