Questions about the S1,C1,T1 combo mode.

[xaelsouth]

Questions about the S1,C1,T1 combo mode.

[alalons]

I have been testing a new approach, see my fork.
In this fork depending on sample rate and decimation I have been getting different rssi values. I have enabled decimation in steps smaller than one and sample rate adaptable in multiples of 800k times decimation.
Best results with my test gear at decimation 2.7 and 2160000 Hz bandwidth with rssi 150

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?

[xaelsouth]

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 wmbusmeters rtlwmbus:c1,t1,s1:sdr@-f=868.7M,-s=1600000:wmbus@-s which will allow users to specify command lines of rtl_sdr and rtl_wmbus as they want. You just define a best guess default value for the most common case and left further optimizations to be done by users.

[xaelsouth]

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:

• checkout newest rtl_wmbus version. I have slightly optimized in the main loop: less float additions and divisionst
• do you really need atan() from libm or an replacement is sufficient
• deactivate run length algorithm or comment it out. You will not need that, probably. It's actually redundant to time2 method
• make filter using fixed-point arithmetic instead of float

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.

[alalons]

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.
as shown by the data of profiler gprof in the pull request comments, it does halve execution time of the frequency shifting.
But as also mentioned there the main point susceptible for optimization if any possible are FIR an IIR and moving average filters which account for most of cpu usage.
The fractional decimation was a naive attempt to reduce samples per second at a minimum.

[xaelsouth]

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.