-
Notifications
You must be signed in to change notification settings - Fork 45
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Questions about the S1,C1,T1 combo mode. #19
Comments
I have been testing a new approach, see my fork. At decimation 1.15 and 929000Hz bandwidth rssi decreases to 80 At higher bandwidths started to decay rssi. Xael, what do you think? Is there an optimum sample rate. Why does rssi depend (apparently) on sampling rate? |
Hello Fredrik. Well, i did not take any quantitative tests, therefore i can not definitely tell in which case receiving telegrams would be better or worse. Anyway, receiving telegrams at an intermediate frequency (in our case at 868.7MHz) means that frequency translation (or shifting by multiplication) is needed. Every additional step in the signal processing chain means introducing more rounding errors, that could reduce the overall sensitivity by a few decibels. Sounds bad, but is absolutely no issue as the devices are located relatively close to receiver and there are no obstacles (like multiple concrete walls). To my opinion you would better stick with something like |
Hello alalons, To get rid of RSSI value fluctuations you probably need to normalize output from mavgi_filter() by the decimation rate. But why?.. rtl_wmbus has been designed with efficiency in mind. I don't think that decimating the sample rate as you want will be expedient. Downsampling (and upsampling) will usually be done by an integer step: 2,3,4.... Another case like yours is basically a resampling by a ratio. It's not trivial and means that first upsampling and then downsampling with additional post-filtering is needed (or first downsampling and then upsampling with pre-filtering) that will eat CPU cycles. Decimation in rtl_wmbus is implemented as moving average filter, which is a kind of low-pass filter. This allows a very simple and efficient downsampling by an integer value, which is 2 by default. If a low-pass FIR filter would be used, it would load the CPU heavier and require filter coefficients to be recalculated for a given sample rate an every program start. If you faced poor performance (1xCPU system?) check following:
And measure and measure and measure execution speed on every change you make. I suggest to record the radio for one or two minutes into a file and always test rtl_wmbus fork with your modifications against. This will make your measures comparable and you will immediately see how your modifications affect execution speed and the receiver quality. |
I have no need to optimize speed right now. Just had the happy idea of computing both frequency shifts at the same time halving the number of float multiplications involved in complex computation. |
Fredrik, take the new rtl_wmbus version from today with alalon's optimizations included. Please note, that the new frequency for simulataneous receiving of S1 and T1/C1 has moved from 868.7MHz to 868.625MHz! I will close this issue here. |
I saw the new support for S1 mode and have a quick question.
Does rtl-wmbus receive C1/T1 telegrams better when rtlsdr is tuned to 868.95MH (with potential fine tuning)?
Or is it equally good at receiving C1/T1 telegrams if I use the new -s option and 868.7MH ?
Likewise compared to S1 telegrams and rtlsdr tuned to 868.3M.
My intent was to write logic so that:
wmbusmeters rtlwmbus:c1,t1
will tune to 868.95M and
wmbusmeters rtlwmbus:s1
will tune to 868.3Mand
wmbusmeters rtlwmbus:c1,t1,s1
will tune to 868.7M and add -s.But if the last c1,t1,s1 combo is just as good at receiving telegrams, then I could just
let wmbusmeters to always default to this setting and my code will be simpler.
What do you think?
The text was updated successfully, but these errors were encountered: