dtrackj_report_20060903

BWTrack

作業記録 †

受信例。
}と=で改行している。
カーソルが末尾まで進んだ場合は、3行目の先頭に戻って上書きしている。
まだまだ解りにくいですね。

この時の受信データは、
JA1YKX>APS228,WIDE:}JQ6QYA>RELAY,TCPIP,JA1YKX*:=3151.73N/13055.95E-Miyazaki Miyakonojo Kirisima {UIV32N}

12345678901234567890

JA1YKX>APS228,WIDE: 　　}検出で強制改行
JQ6QYA>RELAY,TCPIP,J　　行末に来たので自動改行
A1YKX*　　　　　　　　　=検出で強制改行
3151.73N/13055.95E-M　　行末に来たので強制改行→末尾なので3行目の頭に移動。

で、続いて3行目の頭から上書きされて、

12345678901234567890

JA1YKX>APS228,WIDE:
JQ6QYA>RELAY,TCPIP,J
iyazaki Miyakonojo K　　ここから続きの文字列が上書きされている。
irisima {UIV32N95E-M　　　　UIV32Nで終わりだが、前の文字が残っているのでこうなる。

表示する文字列を制限するため、デリミタ検出にてフラグを立ててマスクする事を検討します。
1個目のカンマが来たらそこでマスクON、しばらく表示させないでいて、次にイコールが
来たら改行してからマスクOFF。ここから緯度経度が2行目に表示される。
次にハイフンが来たら改行。
フラグの組み合わせをうまく使わないと、メッセージ中の文字で誤動作しそう。

しかし困ったな。
I-GATEから飛んできたRFは、頭にI-GATE局のIDが先に付くんですね。
行の頭がオリジナル送信局CALLじゃないってのがかなり痛い。
複雑なテキストはPIC16F84ではRAM不足で難しいから、割り切りも必要かな？

最新の20件