アカウント名:
パスワード:
> 1日1回の位置データの送信なら、コイン電池で10年動作可能ということだけど、これは1回/日x365日/年x10年=3650回に相当。GPSの補足はスタンバイから10秒ぐらいかかると思う。10秒を3650回と考えると10時間ぐらい。5秒と考えても5時間。とてもじゃないけどボタン電池ではそんな時間GPS動かせない。
救命用の位置情報送信端末として設計するなら太陽電池つきのジャケットへ埋め込みかな。
救助ビーコンの場合、何もGPS情報を送信する必要はなくてそのままﾋﾟｺｰﾝ ﾋﾟｺｰﾝ とひたすら単純な信号を送信しつづけてくれればいいですよ受信側でそれがどこにいるか探せれば良いんですから
# FOXハンティングの時間だ!
通信せずブロードキャストするだけならなにもこの技術で無くてよいのでは
救難信号には常時はGPS信号はいらないという意味では?救援側から要請があり、かつ、電池に余裕がるときだけ遭難側がGPSで位置検出して送信し、通常は単なるビーコンという使い方でいいと思いますけど。
> 救援側から要請があり、かつ、電池に余裕がるときだけ遭難側がGPSで位置検出して送信し、
受信にも電力が必要だと知らんのか？いつ来るかわからん信号をずっと待ち続ける間も電力を使うんだぞ。
受信も10分に1回とか1時間に1回とかすりゃいいだろうし少なくとも送信よりは電力を食わないよね。
ああいえばこう言ってそんなにソニーの通信技術気に入らないのか。厚木にどんな恨みがあるんだろう
# この手のは厚木じゃないか
> 受信も10分に1回とか1時間に1回とかすりゃいいだろうし
いやｗｗｗｗ 相手がいつ送ってくるかわからないのに「受信も10分に1回とか1時間に1回とかすりゃいいだろうし」とかじゃ意味ないだろｗ
> ああいえばこう言ってそんなにソニーの通信技術気に入らないのか。
いや、あんたが単に技術音痴で無茶なこと言ってるだけなんだが。
救助ビーコン(遭難側)でこの技術使うなら受信は10分に1回とか1時間に1回とかして捜索側の信号を受信したら受信頻度を上げるって仕様にするよねぇ…
相手(捜索側)がいつ送ってくるか判らないから常に受信状態にしておくってのは無駄な電力使う悪手だと思うんだけど。いつ救助が来るか判らないからこそ、できるだけビーコンが長い期間生きるようにするってのは、
技術音痴だとしても、考えればそれぐらいでてくるけどねえ…
そのシステムでは遭難者側が捜索側の信号を受信しそこなったら、何も始まらんぞ。遭難側の装置は小型で受信性能も悪いのだから。
遭難者側が受けとるべき情報って、近くに捜索が来ていること、だと思うのでそれまではビーコン送りっぱなしでいいと思うんですよ。
逆に受信性能が悪いということは近くだと通信できるということで近くにいるのは確かだがどこにいるのか判らない、という時間を短縮できると思いますよ。
# だと今回の技術じゃなくてもいいのかwww
ええ？今の話ってGPS情報をどういうタイミングで取得して送るかっていう話じゃないの？捜査側は遠くにいるときこそそういう情報が欲しいでしょ。
そういうのは遭難時に1度で良い様に思うが。
80bpsとはいえ意味のある情報を送れるのですから、遭難側からの信号に次回の受信のタイミングを乗せればいいんじゃないかと思います。また、電池もコイン電池ではなくこの手 [panasonic.com]の大型で容量の大きなものを使っても救難信号用途なら問題とはならないでしょう。
否定をしたいから否定するのなら勝手に続けてくださって結構ですが、ここの本来の趣旨である雑談をしたいのなら消えてください。
単純に下記情報を繰り返せばいいんじゃないの。これだと70bitだから1秒で送り出せるし。 機器ID(48bit) + 送信間隔[sec](16 bit) + 非常事態フラグ(1bit) + 状態フラグ(急病・怪我)(2bit)+ 電池残量( 3 bit)
特定の時間帯だけ連続発信モードにしてFOXハント対象者に余裕をつくるという工夫をしてもいいし、電源に余裕があるなら周辺温度(8bit)や稼働経過時間(64bit)を追加してもいいし。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはただ死んだだけでなく、本当にひどい臭いを放ち始めている -- あるソフトウェアエンジニア
送受信は低消費電力でも周りが・・・ (スコア:0)
> 1日1回の位置データの送信なら、コイン電池で10年動作可能
ということだけど、これは1回/日x365日/年x10年=3650回に相当。
GPSの補足はスタンバイから10秒ぐらいかかると思う。10秒を3650回と考えると10時間ぐらい。5秒と考えても5時間。
とてもじゃないけどボタン電池ではそんな時間GPS動かせない。
救命用の位置情報送信端末として設計するなら太陽電池つきのジャケットへ埋め込みかな。
Re: (スコア:1)
救助ビーコンの場合、何もGPS情報を送信する必要はなくて
そのままﾋﾟｺｰﾝ ﾋﾟｺｰﾝ とひたすら単純な信号を送信しつづけてくれればいいですよ
受信側でそれがどこにいるか探せれば良いんですから
# FOXハンティングの時間だ!
Re: (スコア:0)
通信せずブロードキャストするだけならなにもこの技術で無くてよいのでは
Re:送受信は低消費電力でも周りが・・・ (スコア:0)
救難信号には常時はGPS信号はいらないという意味では?
救援側から要請があり、かつ、電池に余裕がるときだけ遭難側がGPSで位置検出して送信し、
通常は単なるビーコンという使い方でいいと思いますけど。
Re: (スコア:0)
> 救援側から要請があり、かつ、電池に余裕がるときだけ遭難側がGPSで位置検出して送信し、
受信にも電力が必要だと知らんのか？いつ来るかわからん信号をずっと待ち続ける間も
電力を使うんだぞ。
Re: (スコア:0)
受信も10分に1回とか1時間に1回とかすりゃいいだろうし
少なくとも送信よりは電力を食わないよね。
ああいえばこう言ってそんなにソニーの通信技術気に入らないのか。
厚木にどんな恨みがあるんだろう
# この手のは厚木じゃないか
Re: (スコア:0)
> 受信も10分に1回とか1時間に1回とかすりゃいいだろうし
いやｗｗｗｗ 相手がいつ送ってくるかわからないのに
「受信も10分に1回とか1時間に1回とかすりゃいいだろうし」
とかじゃ意味ないだろｗ
> ああいえばこう言ってそんなにソニーの通信技術気に入らないのか。
いや、あんたが単に技術音痴で無茶なこと言ってるだけなんだが。
Re:送受信は低消費電力でも周りが・・・ (スコア:1)
救助ビーコン(遭難側)でこの技術使うなら受信は10分に1回とか1時間に1回とかして
捜索側の信号を受信したら受信頻度を上げるって仕様にするよねぇ…
相手(捜索側)がいつ送ってくるか判らないから常に受信状態にしておくってのは
無駄な電力使う悪手だと思うんだけど。いつ救助が来るか判らないからこそ、
できるだけビーコンが長い期間生きるようにするってのは、
技術音痴だとしても、考えればそれぐらいでてくるけどねえ…
Re:送受信は低消費電力でも周りが・・・ (スコア:1)
そのシステムでは遭難者側が捜索側の信号を受信しそこなったら、何も始まらんぞ。
遭難側の装置は小型で受信性能も悪いのだから。
Re:送受信は低消費電力でも周りが・・・ (スコア:1)
遭難者側が受けとるべき情報って、近くに捜索が来ていること、だと思うので
それまではビーコン送りっぱなしでいいと思うんですよ。
逆に受信性能が悪いということは近くだと通信できるということで
近くにいるのは確かだがどこにいるのか判らない、という時間を短縮できると思いますよ。
# だと今回の技術じゃなくてもいいのかwww
Re: (スコア:0)
ええ？今の話ってGPS情報をどういうタイミングで取得して送るかっていう話じゃないの？
捜査側は遠くにいるときこそそういう情報が欲しいでしょ。
Re: (スコア:0)
そういうのは遭難時に1度で良い様に思うが。
Re: (スコア:0)
80bpsとはいえ意味のある情報を送れるのですから、遭難側からの信号に次回の受信のタイミングを乗せればいいんじゃないかと思います。
また、電池もコイン電池ではなくこの手 [panasonic.com]の大型で容量の大きなものを使っても救難信号用途なら問題とはならないでしょう。
否定をしたいから否定するのなら勝手に続けてくださって結構ですが、ここの本来の趣旨である雑談をしたいのなら消えてください。
Re: (スコア:0)
単純に下記情報を繰り返せばいいんじゃないの。
これだと70bitだから1秒で送り出せるし。
機器ID(48bit) + 送信間隔[sec](16 bit) +
非常事態フラグ(1bit) + 状態フラグ(急病・怪我)(2bit)+ 電池残量( 3 bit)
特定の時間帯だけ連続発信モードにしてFOXハント対象者に余裕をつくるという工夫をしてもいいし、
電源に余裕があるなら周辺温度(8bit)や稼働経過時間(64bit)を追加してもいいし。