Reputation: 111
I am currently working modifying some code I found on Github. It is for a spectrum analyzer using ath9k-based wireless cards.
Anyways, the issue is with this bit of code here:
sdata = struct.unpack_from("56B", data, pos)
pos += 56
# calculate power in dBm
sumsq_sample = 0
samples = []
for raw_sample in sdata:
if raw_sample == 0:
sample = 1
else:
sample = raw_sample << max_exp
sumsq_sample += sample*sample
samples.append(sample)
print (len(samples))
I expect the last print statement to always produce the value "56", however I have run into some strange behavior. Here is some example output:
56
56
56
56
56
56
56S 15.952354
56
56
56
56
56
56
56
56
56
56
56
56
56S 15.689883
56
56S 16.510071
56
56S 17.591084
56S 18.358299
56
56
56
56
56
56
56
56
56
56
56
56
56
56
56
56
56
56
56
This makes no sense to me. I have checked the documentation for len() and struct.unpack_from(), but haven't gotten anywhere. Samples should contain 56 one-byte integers but occasionally I get odd values like "56S 10.237633"
Github repo of project I am modifying can be found at https://github.com/bcopeland/speccy Code sample above is from spectrum_file.py starting at line 87
Any ideas? Thanks
Upvotes: 1
Views: 98
Reputation: 2067
As mentioned by @kchomski, your issue is due to another part of your program writing to stderr
.
I found the following line of code in speccy.py
, which I believe is causing the unexpected output:
sys.stderr.write('FPS %f \r' % (sum(self.fps) / len(self.fps)))
An MVCE would be the following:
import sys
sys.stderr.write('TOSTDERR\r')
print('54')
which outputs:
54STDERR
The carriage return character \r
is moving your cursor back to the beginning of the line and then the 54
is printed on top of what was previously written to stderr
.
You can resolve the issue by switching \r
to \n
which will put a new line at the end of the output to stderr
and avoid this issue of overwriting.
Upvotes: 2