14)join
joinするにはマネージャーが必要になる。
ここは覚悟をきめてもう1台準備しよう。
mote側のappは01-joinのjoin_app.cを使用するのだが、固定データを送るだけでは面白くないので、消費電流(Qtotal)、稼動時間(UpTime)、温度を送信してみよう。
これらの値は dnm_loc_getParameterCmd の DN_API_PARAM_CHARGE で取得できる。
呼び方はこのようになる。
dnErr = dnm_loc_getParameterCmd(
DN_API_PARAM_CHARGE, // paramId
chargeBuf, // payload
0, // txPayloadLen
&respLen, // rxPayloadLen
&rc // rc
);
ASSERT(dnErr==DN_ERR_NONE);
ASSERT(rc==DN_ERR_NONE);
バッファ(chargeBuf)に12バイトのデータが入る。
データ構造(dn_api_rsp_get_charge_t)は dn_api_param.h に書かれている。
/**
\brief Payload of the request to get parameter #DN_API_PARAM_CHARGE.
*/
typedef dn_api_get_hdr_t dn_api_get_charge_t;
/**
\brief Payload of the response when getting parameter #DN_API_PARAM_CHARGE.
*/
typedef struct {
INT8U rc; ///< Return code, among values in #dn_api_rc_t.
INT8U paramId; ///< Parameter identifier. Set to #DN_API_PARAM_CHARGE.
INT32U qTotal; ///< Charge since last reset, in milli-coulombs.
INT32U upTime; ///< Time since reset, in seconds.
INT8S tempInt; ///< Temperature (integral part, in C).
INT8U tempFrac; ///< Temperature (fractional part, in 1/255 of C).
} dn_api_rsp_get_charge_t;
実行結果は下図のようになる。
マネージャーに接続後、5秒ごとに10バイトのデータを送信し、その内容をCLIに吐き出す。
APIExplorerで見るとこんな感じだ。
消費電流(Qtotal)、稼動時間(UpTime)ともRESETでクリアされてしまうので、長時間の積算値が必要な場合は、どこかに保存しておくような工夫をするしかない。
moteとマネージャーのどちらを先に立ち上げるかによって、消費電流(Qtotal)の値は変化する。
マネージャーがいる状態でmoteに電源を入れると、消費電流(Qtotal)は必要最小限の値から始まる。
逆に先にmoteに電源を入れ、しばらくしてからマネージャーの電源を入れると、かなり大きい値からQtotalの値が表示されるはずだ。
後者のパターンを試す時、マネージャーの電源を入れる前に、CLIから"minfo"と打つとstateがSearchとなっていると思う。
moteが同じnetidの親(マネージャー)を探しているのである。
この間、かなり電気を食ってしまう。
また、CLIから"mget joindc"と打つと
joindc = 64
といった値が帰ってくるはずだ。
この値は親(マネージャー)を探す時間と休む時間の比率を表している。
255が100%でつねに探していることになり、見つかるまでの時間は最短になるが消費電流は最大になる。
64は25%で、例えると1秒探したら3秒休むといった感じで、当然ながら100%の時よりも見つかるまでの時間は長くなるが消費電流はおよそ1/4になる。
joindc以外にもいくつかパラメータがあり、設置されている状況によって、バランスの良い設定を決める必要がある。
□ソースをこちらに置きました。
mote4
ここは覚悟をきめてもう1台準備しよう。
mote側のappは01-joinのjoin_app.cを使用するのだが、固定データを送るだけでは面白くないので、消費電流(Qtotal)、稼動時間(UpTime)、温度を送信してみよう。
これらの値は dnm_loc_getParameterCmd の DN_API_PARAM_CHARGE で取得できる。
呼び方はこのようになる。
dnErr = dnm_loc_getParameterCmd(
DN_API_PARAM_CHARGE, // paramId
chargeBuf, // payload
0, // txPayloadLen
&respLen, // rxPayloadLen
&rc // rc
);
ASSERT(dnErr==DN_ERR_NONE);
ASSERT(rc==DN_ERR_NONE);
バッファ(chargeBuf)に12バイトのデータが入る。
データ構造(dn_api_rsp_get_charge_t)は dn_api_param.h に書かれている。
/**
\brief Payload of the request to get parameter #DN_API_PARAM_CHARGE.
*/
typedef dn_api_get_hdr_t dn_api_get_charge_t;
/**
\brief Payload of the response when getting parameter #DN_API_PARAM_CHARGE.
*/
typedef struct {
INT8U rc; ///< Return code, among values in #dn_api_rc_t.
INT8U paramId; ///< Parameter identifier. Set to #DN_API_PARAM_CHARGE.
INT32U qTotal; ///< Charge since last reset, in milli-coulombs.
INT32U upTime; ///< Time since reset, in seconds.
INT8S tempInt; ///< Temperature (integral part, in C).
INT8U tempFrac; ///< Temperature (fractional part, in 1/255 of C).
} dn_api_rsp_get_charge_t;
実行結果は下図のようになる。
マネージャーに接続後、5秒ごとに10バイトのデータを送信し、その内容をCLIに吐き出す。
APIExplorerで見るとこんな感じだ。
消費電流(Qtotal)、稼動時間(UpTime)ともRESETでクリアされてしまうので、長時間の積算値が必要な場合は、どこかに保存しておくような工夫をするしかない。
moteとマネージャーのどちらを先に立ち上げるかによって、消費電流(Qtotal)の値は変化する。
マネージャーがいる状態でmoteに電源を入れると、消費電流(Qtotal)は必要最小限の値から始まる。
逆に先にmoteに電源を入れ、しばらくしてからマネージャーの電源を入れると、かなり大きい値からQtotalの値が表示されるはずだ。
後者のパターンを試す時、マネージャーの電源を入れる前に、CLIから"minfo"と打つとstateがSearchとなっていると思う。
moteが同じnetidの親(マネージャー)を探しているのである。
この間、かなり電気を食ってしまう。
また、CLIから"mget joindc"と打つと
joindc = 64
といった値が帰ってくるはずだ。
この値は親(マネージャー)を探す時間と休む時間の比率を表している。
255が100%でつねに探していることになり、見つかるまでの時間は最短になるが消費電流は最大になる。
64は25%で、例えると1秒探したら3秒休むといった感じで、当然ながら100%の時よりも見つかるまでの時間は長くなるが消費電流はおよそ1/4になる。
joindc以外にもいくつかパラメータがあり、設置されている状況によって、バランスの良い設定を決める必要がある。
□ソースをこちらに置きました。
mote4
コメント
コメントを投稿