STM32F103C8T(BluePill）は72MHzと今までのATMEGA328P8MHzの９倍の速度なので、サンプリング周波数を従来の9msecからどれだけ上げられるか試してみたら、意外と途中でデータ飛びが発生してしまって4msecでもデータ飛びが発生するので、おかしいと思って解析を始めました。
●現象
マイコンの3.3V電源から供給した場合は１分間4msecループを１５０００回まわした時のTeraTermタイムスタンプが60.05sec程度で収まっているのですが、電池でドライブするときは、１分ループで55secとかデータの読み飛ばしが頻繁に発生する現象を発見しました。Ｘｂｅｅのバッファ処理かＵＳＢシリアルのバッファ処理が破綻する場合があるのかと思います。
確認１：Xbeeへの転送プログラム
115200bpsは固定（4msecサンプリング以下を目標にしている）で、TIcker割り込みで4msec毎に下記flip関数を
実行させてます。printf後転送遅延があるので、waitをいれてありますが、これも無いより在ったほうがいい程度でした。
void flip(){
n++;
pc.printf(“%d,%d\n\r”,n,t.read_ms());
wait_us(3000);
if(n>15000){
flipper.detach();
}
}
確認２：オシロでDCDC出力波形をみてみると
①中華ＤＣＤＣ
GAOHOUDC-DC昇圧コンバータモジュールT2005
これの出力をオシロでみると
ＰｔｏＰで170mVと大きな三角波形です。
②コンデンサでリップル減らし
２２０μＦでは足りなかったので４７０μＦまで大きくしました。
折角小さな基板にしようとしたのに、こんなデカいコンデンサを付加しないとないのが残念ですが、データが欠落してはしょうがないです。
周波数が４０ＫＨｚと倍増して、PtoPが100mVになりました。
＝＞これでＸｂｅｅのデータの１分ループ測定すると60.053secとなったので、データの欠落はマイコン電源と同程度までなったので、この４７０μＦコンデンサ対策を採用することにしました。
●他のＤＣＤＣではどうか？
秋月で買っておいたHT7733Aも基板作って確認してみたのですが、同程度のリップル波形でしたので、面積の小さい中華ＤＣＤＣを採用しました。世の中の皆さんもどうやってＨＴ７７３３Ａを使っているのかをみたら、
やはり100mV超えのリップルがでてコンデンサでつぶされている事例がありました。
http://mamanarazu.jugem.jp/?page=2&month=201510
●結論
ＣＰＵのクロックが速くなったおかげ、今まで見えてなかった原因がみえてきてよかったです。
今まで、クランクのＸｂｅｅ転送データ全然同期してなかった原因の一つとして、Ｘｂｅｅが電源リップル波形に弱いということです。最も良いのは、電源をステップアップＤＣＤＣにしないで、
高い電圧の電池で、レギュレータで降圧するのが最も安定した電源波形がでるのでないかと思います。今回は、単四２個使いのスペースしかないのですが、５Ｖでこのスペースに入る電池をさがしておきます。
●以後
ＣＰＵが９倍速くなったので電池寿命が気になるので、
何時間もつか測定してみます。その際のデータ欠落も測定してみます。
