cでも取りこぼしがｗ

sampling_start_lev : 1
sampling_end_lev   : 1
length : 82
179 54 26 54 26 54 26 54 26 54 26 54 26 54 74 53 26 67 74 54 26 54 73 54 74 54 26 54 73 54 26 54 73 67 26 54 26 55 40 39 27 53 26 55 26 53 27 54 25 67 74 54 73 54 74 54 73 54 74 54 74 54 26 54 25 64 74 54 26 54 73 54 74 54 26 54 26 54 73 54 73 47
start : 1595056508 438491
p1 : 572
p2 : 50579
p3 : 70581
p4 : 70582
p5 : 70582
p6 : 70583
p7 : 1074864
p8 : 1074864
bitcount : 39

ごりごりっと受信した信号を5バイトに落とし込むまでは作れたので様子を見ているといきなりデータの受信で失敗。

このパターンは最初に179とか確実に怪しい数字が。何回か実行しているとこれがデータ部分でもpythonで実行したときと同じような怪しい部分が。頻度としてはあんま変わらない気がする。気持ち減った気はするけど、主観的要因が混じっているのでなんとも。

ループ中のカウンタをコメントとして外していたので、復活させてループカウンタも表示させてエラーの様子を見てみた。

sampling_start_lev : 1
sampling_end_lev   : 1
length : 82
sampling data :
20 78 82 53 27 54 25 55 26 54 26 53 27 54 26 54 73 54 25 68 73 54 27 53 74 54 74 54 26 53 26 54 27 54 72 67 27 54 26 54 26 54 26 54 26 54 26 54 26 54 25 67 74 54 73 54 74 54 74 54 73 54 73 135 72 65 73 54 26 54 74 54 74 53 27 54 25 55 25 55 25 46
sampling loop counter :
39 147 155 105 52 100 51 106 45 107 51 98 52 103 44 106 137 107 49 124 146 98 47 99 139 106 139 102 47 105 50 100 52 107 133 127 52 105 51 100 51 106 45 106 51 100 51 106 44 105 49 124 144 100 143 101 144 98 142 96 143 97 144 191 142 120 144 99 51 106 139 107 138 104 46 104 50 99 51 105 49 84
start : 1595057402 775061
p1 : 616
p2 : 50822
p3 : 70824
p4 : 70825
p5 : 70825
p6 : 70826
p7 : 1075012
p8 : 1075012
bitcount : 39

CPUクロックの変動で処理落ちしているのかとも思ったんですが、ループカウンタをエラーの前後で見比べてみても極端に変わってなさそう？

エラーの６個前のデータは、54μs 98回   1ループ0.55us 1usあたり1.81

エラーの６個後のデータは、54μs 106回 1ループ0.50us 1usあたり1.96

エラーの部分は、135us 191 1ループ0.70us  1usあたり1.41回

サンプリングが足りないかな？ちょっと表計算に打ち込んで数字を並べてみましょう。

数字はA列から信号の時間(μs)、その時にループが回った回数。C列は1ループ当たりの時間で、最後のDが1μs当たりのループ回数となっています。エラーの部分ではパフォーマンスが極端に落ちています。それと誤差レベルですがエラー後で少し１ループ当たりの時間が小さくなっている雰囲気はあります。

raspberry pi 3bで時間の取得を行うと1μs程度かかっているので、GPIOのピンの読み込み時間の計測をしてエラーを出した方がいいのかな？プロセス自体の処理が止まってる可能性もあるので何とも言えませんが…

CPUクロックの変動が原因かもしれないので、設定を調べてみると、

pi@rasp3b:~ $ cpufreq-info -p
600000 1200000 ondemand
pi@rasp3b:~ $ cpufreq-info -f
600000

なんとも言えませんが、powersaveにして変動しにくくしてみるのも手かもしれない。

せっかくほとんどcで起こしたのになんか残念なことにｗ

sampling_start_lev : 1
sampling_end_lev   : 1
length : 84
sampling data :
20 79 81 54 26 54 26 54 26 54 26 54 27 53 26 54 74 54 25 67 74 54 26 54 74 53 74 54 26 54 26 54 26 54 73 67 26 54 26 54 27 53 27 53 26 54 27 53 27 53 26 67 74 53 74 54 74 54 73 54 74 54 73 54 27 53 73 64 74 54 26 54 74 54 73 54 26 54 26 54 26 54 25 47
sampling loop counter :
65 261 276 182 89 179 89 179 83 182 92 178 89 190 97 211 281 211 96 258 287 206 101 209 282 209 280 210 97 207 101 205 101 207 280 257 102 209 102 206 101 203 103 209 101 205 101 209 98 209 96 257 284 206 286 205 285 206 279 212 285 206 287 205 100 205 283 246 286 205 101 209 282 209 282 209 92 189 95 174 90 185 85 154
start : 1595057404 672245
p1 : 582
p2 : 50826
p3 : 70827
p4 : 70828
p5 : 70828
p6 : 70829
p7 : 1075015
p8 : 1075015
bitcount : 40
data high '0' : 25 ～ 27
data high '1' : 73 ～ 74
data low : 53 ～ 67
data : 02 B1 00 FD B0

上手く受信できれば、かなり精度が高い感じなんですけどねぇ

sudo cpufreq-set -g powersaveで様子を見ていますが、取りこぼしが無くなった気配…この状態でpythonのものを動かすと取りこぼしが発生しているので、cの方が安定度は高そうというのが少しだけ救いかもｗ