Paul
What type of dongle are you using? I'm using a NESDR Smart which is
decoding packets. I also have a NESDR mini 2 SDR running right now that is
not decoding any packets using - fc 71000.
Rich
>
Luc and Paul
I re-positioned my RPI and antenna and start over with Paul test and Good
news it failed the first 5 attempts at decoding then it decoded 50 out of
51 packets. Going to run a 24 hour test with this dongle to see how the
driver performs.
This is a common problem. For example, on the Vantage, the transmitter
battery status only appears in LOOP packets, not archive records.
The solution is to let WeeWX accumulate the packets, then extract a value
at the end of the archive interval. You can extract the average value
(which is what
The Local Oscillator frequency.
On Monday, March 25, 2019 at 7:39:08 PM UTC-4, kobuki wrote:
>
> Sorry, but what is "Oscillator Frequency"? It's not the tune-in frequency,
> I assume?
>
> On Tuesday, March 26, 2019 at 12:36:35 AM UTC+1, rich T wrote:
>>
>> Kobuki
>>
>> I use Kalibrate to
On Monday, March 25, 2019 at 7:39:08 PM UTC-4, kobuki wrote:
>
> Sorry, but what is "Oscillator Frequency"? It's not the tune-in frequency,
> I assume?
>
> On Tuesday, March 26, 2019 at 12:36:35 AM UTC+1, rich T wrote:
>>
>> Kobuki
>>
>> I use Kalibrate to determine the ppm. Works pretty
Sorry, but what is "Oscillator Frequency"? It's not the tune-in frequency,
I assume?
On Tuesday, March 26, 2019 at 12:36:35 AM UTC+1, rich T wrote:
>
> Kobuki
>
> I use Kalibrate to determine the ppm. Works pretty good. The formula I
> used was ppm * Oscillator Frequency / 100.
>
> Rich
Kobuki
I use Kalibrate to determine the ppm. Works pretty good. The formula I
used was ppm * Oscillator Frequency / 100.
Rich
On Monday, March 25, 2019 at 7:21:40 PM UTC-4, kobuki wrote:
>
> Absolute error, based on PPM: measured_ppm / 1 000 000 * F - for F = 911
> MHz or F = 911 000
I see. Actually it's a great start if it gets stable with a constant offset
first, but then it will need to be handled somehow, like providing the
actual offset error to the receiver as a cline parameter.
On Tuesday, March 26, 2019 at 12:23:23 AM UTC+1, Paul Anderson wrote:
>
> Kobuki,
> A ppm
Yes, it's possible to hit a precision barrier with any modern non-realtime
multitasking OS. I think it's still doable, though, but it wouldn't
surprise me if more than 2-3 simultaneous stations would pose a problem.
On Monday, March 25, 2019 at 11:45:05 PM UTC+1, ljm.h...@gmail.com wrote:
>
>
Kobuki,
A ppm calibration offset would be great! Unfortunately the program does not
provide one as of yet, I am well aware that my Freq list may be of little
use to anyone else. It's just a temporary terrible hack to get some
decoded output for now.
Luc,If I take your current US test Freq
Absolute error, based on PPM: measured_ppm / 1 000 000 * F - for F = 911
MHz or F = 911 000 000 Hz it gives 225.928 Hz. But any decent AFC should
correct differences of 5-10 kHz with ease, or even more. This is negligible.
What are you calibrating with and what is the reference frequency
I think it was discussed several times already, and again and again, that
you absolutely must calibrate your sticks before running anything related
to this project. You'd shoot yourselves in the foot applying a fixed offset
that works in a single setup that uses no calibration at all.
Please
Luc
Was wondering what the gain was when the program starts. Look like it is
set for auto.
Rich
On Monday, March 25, 2019 at 4:26:49 PM UTC-4, ljm.h...@gmail.com wrote:
>
> On Monday, 25 March 2019 00:24:25 UTC-3, rich T wrote:
>>
>> Is there a way to display the gain of the SDR when it first
Luc
The fc offset does not work for me. Wondering since each dongle ppm is
most likely different the fc number will vary. Let run kalibrate on the
dongle and figure my offset.
Rich
pi@raspberrypi:~/work/src/github.com/lheijst/rtldavis $
$GOPATH/bin/rtldavis -maxmissed 4 -tf US -fc 71000
On Monday, 25 March 2019 17:59:57 UTC-3, vince...@gmail.com wrote:
>
> You might want to do an altinstall of a later version. Email me if you
> want a script I found that does this nicely on the pi and I'll send it
> tonight...
>
Vince,
Thanks.
Currently all problems are solved and I have
On Monday, 25 March 2019 00:24:25 UTC-3, rich T wrote:
>
> Is there a way to display the gain of the SDR when it first loads?
>
Rich,
The program sets the gain to auto, see command:
if err := dev.SetTunerGainMode(false); err != nil {
log.Fatal(err)
}
When we read back the gain with:
gain :=
If you used
import six
from six.moves import queue
then you want
except queue.Empty
If you are not using six, then you can do something like:
try:
import Queue as queue
except ImportError:
import queue
and the except clause becomes:
except queue.Empty
-tk
On Mon, Mar 25, 2019
I can't speak to the logic of the code, but it looks like it should work
under Python 2 and 3. A couple things to think about:
1. You cannot count on the user having the shim 'six', although it is
becoming increasingly common. Many python installations include it by
default. In any case,
On Monday, 25 March 2019 15:57:14 UTC-3, vince...@gmail.com wrote:
>
> Just in case, what os are you on, which version, and what version of
> python3 are you running ?
>
Vince,
root@pi36:~# uname -a
Linux pi36 4.14.98-v7+ #1200 SMP Tue Feb 12 20:27:48 GMT 2019 armv7l
GNU/Linux
root@pi36:~#
On Monday, 25 March 2019 15:36:08 UTC-3, Tom Keffer wrote:
>
> What's the problem with getting it working?
>
This statemennt:
except Queue.Empty:
All variations I tried gave different errors.
except Queue.Empty:
except Queue.empty:
except queue.Empty:
except queue.empty:
Futhermore: when I
On Monday, 25 March 2019 12:53:01 UTC-3, ljm.h...@gmail.com wrote:
>
> I will try this construction once again.
>
Tom,
I give up; can't get it working. I'll wait for Matthew to convert his
weewx-sdr driver; I've 'borrowed' the code from there.
Luc
On Monday, March 25, 2019 at 11:41:13 AM UTC-4, Louis De Lange wrote:
>
> I am thinking about some workarounds for the genArchiveRecords() methods.
> Since the historical data request does not contain the cost data it would
> be useful to be able to pull the cost from the last record in the
On Monday, 25 March 2019 12:25:29 UTC-3, Tom Keffer wrote:
>
> from queue import Queue
> works for me under Python 3.
>
Tom,
I will try this construction once again.
How should I solve the Python 2: xrange, Python 3: range differences?
Luc
Tom
Thanks for the reply.
As I started implementing genArchiveRecords() I came to realize that it is
a very elegant solution.
However, I am running into a snag and it is related to the type of data
available when I request historical data - the meter only supplies total
kWh delivered, with
Soory, I made a mistake.
> The first snippet should be:
> snippet from cmon.py:
> ===
> def new_archive_record(self, event):
> """save data to database then prune old records as needed"""
> now = int(time.time() + 0.5)
> delta = now -
Hi Tom,
I do not know if this issue is known already.
I got a deadlock in cmon.py, see code and traceback below:
snippet from cmon.py:
===
def new_archive_record(self, event):
"""save data to database then prune old records as needed"""
now =
Luc,
You are very close to having a code base that will run under both Python 2
and 3. Suggestions:
1. Put this at the top to cover your use of multiple arguments to "print":
from __future__ import print_function
2. For a queue, do this:
try:
# Python 2
from Queue import Queue
except
27 matches
Mail list logo
