通信データの仕様

パルス波の辺の長さの長短でデータを表す． 短ければL，長ければHとする． DC成分を発生させないようにするため， 2周期分の波形のうち以下の6通りのパターンのみ使用する．

#   MSB LSB    LSB         MSB
0   L L L L    ￣|＿|￣|＿
1   L L H H    ￣￣|＿＿|￣|＿
2   L H H L    ￣|＿＿|￣￣|＿
3   H L L H    ￣￣|＿|￣|＿＿
4   H H L L    ￣|＿|￣￣|＿＿
5   H H H H    ￣￣|＿＿|￣￣|＿＿

このパターンを2つ組み合わせた6x6=36通りの表現のうち0〜31までを使い2周期で5bit分のデータを出力する． 32〜34は予約，35は通信終了に利用する．

先頭では信号よりも周波数の低い矩形波が1周期分送信された後，7(#1#1)がひとつ送信される． 手前の矩形波は，先頭に来るノイズを読み捨てやすくするため付け加えられている． 7の長さを基準に今後のデータを解析していく．

末尾の35は2つ続けて送信する． 負号の反転を用いて同期しているので，2度続けた方が処理が単純にできるため． 受信側は1つ目の35の時点で通信を終了して良い．

波形は正負が最初から交互に現れている限りどちらから始まってもよい．

一定レベルに満たない信号はただ無視するので断続的にデータを送信しても良い． ただし波形の先頭に大きめのノイズがきやすいようなのでノイズ対策が必要になる． 0付近のゆらぎを吸収する目的と，3DS側からのデータ送信しやすくするための仕様だったが， 3DSからの出力された波形が思ってたより綺麗ではなかったので，おそらくこの仕様はなかったことに．

ヘッダ部

数値は全てリトルエンディアン．

合計32byte．

byte
1       データ形式のバージョン(0)
1       reserved(0)
1       圧縮形式
        0 ... 無圧縮
        1 ... deflate(予定．ver0.01では未実装)
1       データタイプ
        0 ... バイナリデータ
        1 ... テキストデータ(8bit)
        2 ... テキストデータ(16bit)
        3 ... 画像データ(8bit/インデックスカラー)
        4 ... 画像データ(16bit/RGBA5551)
4       データ部のサイズ
4       展開後のサイズ(最大1M) / 無圧縮の場合データ部のサイズと同じになる
4       データ部のチェックサム(adler32)
16      ファイル名．14文字まで．残りは'\0'で埋める．
        利用可能文字「0-9 A-Z @ - _ .」
n       データ部

データ部

数値は全てリトルエンディアン．

バイナリデータ

uint8   data[]

テキストデータ(8bit)

送信側は改行コードLFに揃える． 文字コードが8bitで収まらない文字を，テキスト中で利用していない文字コードに変換しておくことで8bitに収める．

uint8   num_table   // 置換テーブル個数
struct {
    uint8   src     // 変更元文字コード
    uint16  dst     // 変更先文字コード
} table[num_table]  // 置換テーブル
uint8   data[]      // テキストデータ(8bit)

テキストデータ(16bit)

uint16  data[]

改行コードはLFに揃える． (プチコン3号ではTXTで保存するとCRはLFに変換される仕様みたい)

画像データ (8bit/インデックスカラー)

uint16  width           // 幅
uint16  height          // 高さ
uint8   num             // パレットの色数
uint16  palette[num]    // 色データ
uint8   pixels[]        // 画素データ

画像データ (16bit/ハイカラー)

uint16  width       // 幅
uint16  height      // 高さ
uint16  pixels[]    // 画素データ

今後やりたいことメモ

• deflate対応
  • C++でinflateテストまで完了．smilebasic3用に書き直す
  • 圧縮は既存のライブラリを利用する
• 通信の高速化
  • 単純に周波数を上げるのは限界
  • 長短を2段階から3段階に
    • 3段階x4でDC踏まえて使えるのは19通り
    • 現状と同等の仕様として平均1500B/s(20%up)
    • 上手く判定できるのか
  • 余ってる符合を使う
    • ランレングス
    • データ中でよく使われているパターンをあてはめる
• 通信の安定化
  • 自分の環境ではバグと音量設定ミス以外では誤判定出たこと無い
    • DCのってると結構誤判定増えそう
  • HPF
    • それ自身が誤判定の元になりそうな気も
    • 旧3DSで間に合うのか
  • 閾値計測部分でDC成分チェック
    • 効果あるのか
    • 減算1つくらいなら旧3DSでも大丈夫か？
• CUI版P/SEND
  • 単純にwav生成でいいかも
  • 自分以外使わなさそう
• リファクタリング
  • 高速化部分はしかたないけど，ちょっとコード書きなぐりすぎてて辛い
  • コード書き直したら変数表とかも公開する
• その他
  • バイナリデータのサイズが4バイト区切りというのはどうなのか
    • 最初か最後にサイズ入れるべきではないか
  • テキストデータはSLOTにも書き出せるようにする
  • テキストデータの文字変換(全角→半角)あったほうがいい気がする
  • 最初からXON MICしておいて，受信を素早くできるようにする