Log in
Register
Menu
Log in
Register
Home
What's new
Latest activity
Authors
Forums
New posts
Search forums
What's new
New posts
Latest activity
Members
Current visitors
New posts
Search forums
Menu
Log in
Register
Install the app
Install
Forums
Satellite TV receivers & systems support forums
Satellite PC Card Receivers, Internet by Satellite
Blindscan on linux with tbs cards
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Reply to thread
Message
<blockquote data-quote="deeptho" data-source="post: 1133114" data-attributes="member: 215446"><p>The 400kHz sample rate is the maximum, according to the documentation.</p><p>After some investigation, I can confirm that most of the time in spectrum acquisition is spent</p><p>on i2c transfers, not so much on the FFT itself.</p><p></p><p>Typically, one fft takes 28milliseconds and reading its data takes about 240 ms.</p><p>However the code was not optimal and I could reduce that reading time to 155ms.</p><p>So that saves about 30% of the time in that part of the code. With these changes,</p><p>both polarisations and the high/low bands can then be scanned in 55 seconds.</p><p></p><p>The existing code also read some data that is not used afterwards. After removing needless</p><p>reads, I managed to get some more speedup, leading to only 40s for scanning the 4 bands.</p><p></p><p>The code also reads the spectrum with 32 bit precision, whereas probably 16 bits is more than</p><p>enough. I now implemented an experimental 16 bit mode, which can be activated with</p><p>[CODE]sudo su</p><p>echo 0 > /sys/module/stid135/parameters/fft_mode32</p><p>[/CODE]</p><p></p><p>This new code now only takes 27 seconds for the 4 bands. If I remember correctly, with the older code</p><p>(before any of the optimisations) it took 80 seconds. So that would mean that the new code is almost three</p><p>times faster, which is not a bad result. </p><p></p><p>About sepctrum acquisition on multiple demods in parallel: It appears that locking in the </p><p>code made one scan block until the other was finished. This also means that no other </p><p>activity, like tuning to a new channel, is possible while spectrum scan was running.</p><p></p><p>I removed those locks, but there is still some other problem (corruption of spectra), but that might </p><p>be solvable. </p><p></p><p>The i2c bus will remain the bottleneck: only 1 demod can use it at the same time. The good news is that the new code already uses the i2c bus a lot less, and while one demod is reading fft data, the other can compute a new fft. So some parallelisation will be</p><p>possible and the total parallel spectrum acquisition time will still be less than double the time for one scan</p></blockquote><p></p>
[QUOTE="deeptho, post: 1133114, member: 215446"] The 400kHz sample rate is the maximum, according to the documentation. After some investigation, I can confirm that most of the time in spectrum acquisition is spent on i2c transfers, not so much on the FFT itself. Typically, one fft takes 28milliseconds and reading its data takes about 240 ms. However the code was not optimal and I could reduce that reading time to 155ms. So that saves about 30% of the time in that part of the code. With these changes, both polarisations and the high/low bands can then be scanned in 55 seconds. The existing code also read some data that is not used afterwards. After removing needless reads, I managed to get some more speedup, leading to only 40s for scanning the 4 bands. The code also reads the spectrum with 32 bit precision, whereas probably 16 bits is more than enough. I now implemented an experimental 16 bit mode, which can be activated with [CODE]sudo su echo 0 > /sys/module/stid135/parameters/fft_mode32 [/CODE] This new code now only takes 27 seconds for the 4 bands. If I remember correctly, with the older code (before any of the optimisations) it took 80 seconds. So that would mean that the new code is almost three times faster, which is not a bad result. About sepctrum acquisition on multiple demods in parallel: It appears that locking in the code made one scan block until the other was finished. This also means that no other activity, like tuning to a new channel, is possible while spectrum scan was running. I removed those locks, but there is still some other problem (corruption of spectra), but that might be solvable. The i2c bus will remain the bottleneck: only 1 demod can use it at the same time. The good news is that the new code already uses the i2c bus a lot less, and while one demod is reading fft data, the other can compute a new fft. So some parallelisation will be possible and the total parallel spectrum acquisition time will still be less than double the time for one scan [/QUOTE]
Insert quotes…
Verification
Post reply
Forums
Satellite TV receivers & systems support forums
Satellite PC Card Receivers, Internet by Satellite
Blindscan on linux with tbs cards
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.
Accept
Learn more…
Top