Comments (15)
Could you provide the output for the command: rtlamr -version
from rtlamr.
Build Date: 03-08-2016
Commit: v0.7.1
It's this release:
https://github.com/bemasher/rtlamr/releases/download/v0.7.1/rtlamr_linux_arm.tar.gz
from rtlamr.
I've made a few commits that significantly improve performance. Something still doesn't sound right about the difference in performance between your RPi and RPi2. Could you try running this build as of 17b0016 and let me know how it performs?
from rtlamr.
It's similar, high CPU (100% on a core) but the load is slightly lower.
I connected my old Pi, but that version doesn't even have the version flag yet, the readme of that release is broken but the date is 2014-08-30.
That version is maxing out around 15% with a .25 load.
from rtlamr.
I'm unable to reproduce this on my RPi2, running the latest version shows approximately 10% CPU usage with 5 minute load average of 0.13 using -symbollength=7
.
On v0.5.0 it shows approximately 20% CPU usage and 5 minute average load of 0.22 with the same flags.
Which version of rtl_tcp are you running? Did you build it from source or are you using the package available via raspbian?
Can you provide performance values with no -symbollength
flag?
from rtlamr.
I'm running the latest version, compiled from git according these instructions: http://sdr.osmocom.org/trac/wiki/rtl-sdr
When I run without symbollength CPU is 100% and load climbs to about 1 too, but I am barely getting any messages, maybe 2 in 5 mins where I get about 50 with the older version.
from rtlamr.
It's possible the issue is related to cross compiling the binaries. I've attached a binary that was built on my RPi2 with go1.6.2 armv6l that has the desired performance, let me know if this performs any better.
from rtlamr.
Yes much better! Looking at a 10% CPU with a 0.3 load.
from rtlamr.
Perfect. Unless I can figure out exactly what is broken while cross-compiling for ARM I'll just have to build the ARM binaries on my RPi2 for release. I'll be creating a new release in the near future that will take care of this and incorporate some new performance improvements.
Thanks for opening the issue, I probably wouldn't have ever caught it otherwise.
from rtlamr.
Looks like cross-compiling for ARM statically links the binary while compiling on the RPi2 itself, it dynamically links with interpreter /lib/ld-linux-armhf.so.3. Not sure how to fix this other than building ARM releases on the RPi2.
from rtlamr.
even using the rtlamr.tar.gz included here on my Pi 2 I'm seeing 81.4% CPU usage by rtlamr. Is there anything I can do to decrease that load?
from rtlamr.
That sounds like an appropriate level of CPU usage for rtlamr. The only thing you can really do to reduce load is to use shorter symbol lengths with the -symbollength
flag, which will lower the sample rate. Just keep in mind that shortening the symbol length will reduce receivable bandwidth and will result in fewer messages being received. Below is a set of tables describing valid symbol lengths. The default symbol length is 72 samples per chip.
Symbol Length | Sample Rate |
---|---|
7 | 229.376 kHz |
8 | 262.144 kHz |
9 | 294.912 kHz |
Symbol Length | Sample Rate | Symbol Length | Sample Rate |
---|---|---|---|
28 | 917.504 kHz | 39 | 1.277952 MHz |
29 | 950.272 kHz | 40 | 1.310720 MHz |
30 | 983.040 kHz | 41 | 1.343488 MHz |
31 | 1.015808 MHz | 42 | 1.376256 MHz |
32 | 1.048576 MHz | 43 | 1.409024 MHz |
33 | 1.081344 MHz | 44 | 1.441792 MHz |
34 | 1.114112 MHz | 45 | 1.474560 MHz |
35 | 1.146880 MHz | 46 | 1.507328 MHz |
36 | 1.179648 MHz | 47 | 1.540096 MHz |
37 | 1.212416 MHz | 48 | 1.572864 MHz |
38 | 1.245184 MHz |
Symbol Length | Sample Rate | Symbol Length | Sample Rate |
---|---|---|---|
49 | 1.605632 MHz | 74 | 2.424832 MHz |
50 | 1.638400 MHz | 75 | 2.457600 MHz |
51 | 1.671168 MHz | 76 | 2.490368 MHz |
52 | 1.703936 MHz | 77 | 2.523136 MHz |
53 | 1.736704 MHz | 78 | 2.555904 MHz |
54 | 1.769472 MHz | 79 | 2.588672 MHz |
55 | 1.802240 MHz | 80 | 2.621440 MHz |
56 | 1.835008 MHz | 81 | 2.654208 MHz |
57 | 1.867776 MHz | 82 | 2.686976 MHz |
58 | 1.900544 MHz | 83 | 2.719744 MHz |
59 | 1.933312 MHz | 84 | 2.752512 MHz |
60 | 1.966080 MHz | 85 | 2.785280 MHz |
61 | 1.998848 MHz | 86 | 2.818048 MHz |
62 | 2.031616 MHz | 87 | 2.850816 MHz |
63 | 2.064384 MHz | 88 | 2.883584 MHz |
64 | 2.097152 MHz | 89 | 2.916352 MHz |
65 | 2.129920 MHz | 90 | 2.949120 MHz |
66 | 2.162688 MHz | 91 | 2.981888 MHz |
67 | 2.195456 MHz | 92 | 3.014656 MHz |
68 | 2.228224 MHz | 93 | 3.047424 MHz |
69 | 2.260992 MHz | 94 | 3.080192 MHz |
70 | 2.293760 MHz | 95 | 3.112960 MHz |
71 | 2.326528 MHz | 96 | 3.145728 MHz |
72 | 2.359296 MHz | 97 | 3.178496 MHz |
73 | 2.392064 MHz |
from rtlamr.
Oh I see, so if I only cared about my one meter (which according to meters.csv only transmits between 910 and 920 Mhz) then I could do a symbol length of 7 and set my centerfreq to 915M and should easily get the data I want?
from rtlamr.
Maybe, you'd likely miss a lot of messages since the meter hops between all of the channels it transmits on and your radio will usually only hear messages occurring within the bandwidth it is listening for. A symbol length of 7 has an extremely narrow bandwidth, I would try 7, 8 and 9 to see which is most reliable.
from rtlamr.
Thanks, apologies for hijacking a previous question with what ended up being an unrelated issue!
from rtlamr.
Related Issues (20)
- Support meter type 19? HOT 5
- Stopped working after HAOS 8.5 / Core 2022.8.7 updates HOT 1
- scm+ HOT 1
- Tried in the UK on an Elster AS300P electricity meter HOT 2
- 100W+ Water ERT Module ERW-1300-402 HOT 1
- Integrating American Meter Company model AC-250 Gas Meter HOT 3
- RTL_TCP quits HOT 6
- ITRON 40G - Unable to find meter or no messages? HOT 1
- Poor R900 message reception except with msgtype=all HOT 1
- SCM+ Endpoint ID HOT 1
- r900Parser.filter / quantize takes over 80% of CPU HOT 3
- Is it possible to support G5R1s? HOT 1
- Leak fields HOT 1
- panic on startup HOT 5
- All fcc.io device links return "Internal Server Error - Read" HOT 2
- Notice: Support for X meter?
- R900 meters may need additional decoding? HOT 2
- Filter based on tamper flags or type HOT 1
- Would this work for water meters with UI-1203 protocol?
- Itron 500G stopped working HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from rtlamr.