First i just tried with -s 250k and the both -R and it went down from 70 to 
25%. -Y autolevel -Y squelch then brought it down another 10%

But I'm wondering if this could have impact on the reception quality for 
sensors which are further away? So if i ever try to recieve a signal from a 
station i set up let's say 90 to 100m away? 

I was already impressed with SDR as it finds the WH2310 much faster, i mean 
immediately, after a 2 to 3 minute sensor downtime (don't know if it's the 
distance or just the sensor low on power..just around 30m away though ) as 
the console often needs more than 1 hour to find it again.

Is Influx and grafana easy to learn? I'm really not much of a developer, as 
html, css and lets say the weewx config files already are enough of a 
hassle for me, if I make some error somewhere :D 

So I'll probably never be able to write such a driver, but it would be a 
great solution imo, nearly unlimited weewx data replication possibilities. 
If anyone with some spare time and skills to do it would be open to code 
it. I'd be happy to help with beta testing.

Option c is a bit too much wunderground dependant and the performance is 
often lacking when trying to access wunderground data.

Option a: sounds interesting too, so could i save to an additional mysql 
database on an external device/storage and run wee_reports periodically on 
that device?


matthew wall schrieb am Freitag, 4. März 2022 um 14:18:10 UTC+1:

> On Friday, March 4, 2022 at 6:08:22 AM UTC-5 [email protected] wrote:
>
>> I just found out rtl_433 is the cause of the 70% nonstop cpu usage. I 
>> optimized the rtl_433 command:
>>
>> cmd = rtl_433 -f 868.3M -M time:utc -M protocol -M level -F json -Y 
>> classic -Y autolevel -Y squelch -s 250k -R 78 -R 32
>> (added squelch, autolevel and reduced bandwith to 250k).
>>
>> CPU usage down to 15%, let's see how this goes. Maybe I will try out 
>> whether neowx-material will still occupy the cpu for so long.
>>
>
> thank you for this!  i will add it to the weewx-sdr readme.  do you know 
> how much each of those options affect the performance?  i would guess that 
> the '-R 32' is the biggest one, since that tells rtl_433 to look for only 
> one specific type of data.
>
> as for weewx, the report generation is the biggest load.  i often run 
> multiple (4-5) weewx instances on a low-power machine for data collection, 
> and generate only a single, simple skin for each instance on the data 
> collector.  but i then upload the data to another, more capable machine for 
> aggregation.  i typically use influx for the aggregation, with a grafana 
> front-end.
>
> if you want weewx to generate reports on the aggregation end of things, 
> then you'll have to figure out a way to get the data from the data 
> collector to the aggregator.  i can imagine a few ways of doing this:
>
> a) configure the collector to save to a mysql database, then run the 
> wee_report utility on the aggregator to generate the reports, using the 
> mysql database as the source
>
> b) write a weewx driver that receives data, and a weewx uploader that 
> sends it
>
> c) use the wunderground uploader to send data, and the weewx-interceptor 
> driver to receive it
>
> i am sure there are other options!
>
> m
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/fd73606a-8c71-4ff9-8961-cf4073392f20n%40googlegroups.com.

Reply via email to