Closed jdevelop closed 1 year ago
Unfortunately this demodulator is a lot more involved than the manchester coding used in the rest of the message types.
Probably it could be optimized, but it's not a device I own so I don't have much motivation to spend more time on it than I already have. If someone else would like to take a crack at shoring it up, please do.
@bemasher hi,I got some spare time and I'd like to see if I can optimize the R900 parser code. Any chance you could share some protocol definitions? I googled for that R900 thing and in so far everything I find is a bit vague.
UPD: got this one https://github.com/merbanan/rtl_433/blob/master/src/devices/neptune_r900.c
The current implementation uses matched filters, one for each symbol pair (symbol and it's inversion). Then quantizes the output of those matched filters into the symbol with the best match at each sample in the signal.
These are the symbols: https://github.com/bemasher/rtlamr/blob/dcdddc5a6e7717a038e9346d0adcf9669e4f60b7/r900/r900.go#L132-L134
I noticed that rtl_amr app uses over 85% of CPU on my NUC box ( core i7 ) also tried on my laptop with Xeon, same results.
Tried with most recent "master".
With help of
pprof
I narrowed it down toI can see that this is rather pure math stuff going on in there ( and quite not trivial ), but just in case reporting this as someone can take a look and perhaps come up with some optimizations.