It works for few centimeters only

510 views
Skip to first unread message

Adrián Mihálko

unread,
Jan 29, 2016, 2:56:31 PM1/29/16
to rtl_433
Hi,

I am trying to use rtl_433 on a RPi with my Hama Nano receiver. It works, but for a few centimeters only.

I decided to buy a 433Mhz antenna like this:


But it does not helps at all.

Any other suggestions?

David Woodhouse

unread,
Jan 29, 2016, 6:54:24 PM1/29/16
to Adrián Mihálko, rtl_433
Save some captures when it just stops working, let us take a look...

--
dwmw2

Adrián Mihálko

unread,
Jan 30, 2016, 7:37:30 AM1/30/16
to rtl_433, adria...@gmail.com
Here is what I did today:

I monitored my sensor using SDRSHARP:


(sensor distance 20cm)

As you can see the transmitting frequency is between 433.95Mhz and 434Mhz.

So I changed frequency:

pi@raspberrypi:~ $ rtl_433 -f 433950000


No change, no data from 1 meter distance.

 I changed bit detection level:

pi@raspberrypi:~ $ rtl_433 -f 433950000 -l 1000

Using device 0: Generic RTL2832U

Found Elonics E4000 tuner

Exact sample rate is: 250000.000414 Hz

Sample rate set to 250000.

Bit detection level set to 1000.

Tuner gain set to Auto.

Reading samples in async mode...

Tuned to 433950000 Hz.

2016-01-30 12:23:47 Nexus Temperature/Humidity: House Code 147, Temperature 22.80 C, Humidity 52 %



I just get one reading, no more. If I run again I get no data, so it is not always work.

New measure with SDRSHARP from 1 meter distance:


From 2-3 meter:


My current antenna is a 16cm wire:



Does this info helps? If not, could you please show me how I can save captures what you said?

David Woodhouse

unread,
Jan 30, 2016, 10:33:56 AM1/30/16
to Adrián Mihálko, rtl_433
On Sat, 2016-01-30 at 04:37 -0800, Adrián Mihálko wrote:
>
> Does this info helps? If not, could you please show me how I can save
> captures what you said?

Run 'rtl_433 -a -t' and then show the 'gfilexxx.data' capture files.

You probably want '-l 0' too, for automatic level detection.

--
dwmw2

Robert Terzi

unread,
Jan 30, 2016, 12:48:20 PM1/30/16
to rtl...@googlegroups.com
On 1/30/2016 7:37 AM, Adrián Mihálko wrote:
Here is what I did today:

I monitored my sensor using SDRSHARP:


Very good,  I see you used rtl_tcp, presumably on the RPi?.   This way you can see what the RF environment looks like where you will be receiving.

One more tip, when you do this, change the sample rate in SDRSHARP to 250 Khz, before you connect to rtl_tcp.  That is the sampling rate rtl_433 is using so you will get a more representative picture.



(sensor distance 20cm)

As you can see the transmitting frequency is between 433.95Mhz and 434Mhz.

Just an FYI, depending on the error of your rtl-sdr stick's oscillator this might not be the actual frequency.

Also, How long did you let SDRsharp and rtl_tcp run?      Are you doing your tests after your RTL stick has warmed up?




So I changed frequency:

pi@raspberrypi:~ $ rtl_433 -f 433950000


Make sure you are using a recent build of rtl_sdr, and run with automatic level detection: -l 0.

Changing frequency upwards might actually hurt.  See the center "DC" spike, you don't want your signal right on top of that.  Try moving your frequency down.  433.900 or 433.880.

There are two analyzers that will help you see what's going on.

1. try runs with -a -t to collect gfileNNN.data samples as David suggested.  You will not get any decodes run running in -a mode.  You will get files that can be played back with rtl_433 -r as well as inspected with Audacity or something similar.

2. The pulse analyzer -A will still let the decoders run and the recent code will give you level and frequency estimates.   You may see that you are receiving signals that aren't being matched by any of the decoders because of differences in pulse width.



No change, no data from 1 meter distance.

 I changed bit detection level:

pi@raspberrypi:~ $ rtl_433 -f 433950000 -l 1000

Again try -l 0, make sure you are using a recent rtl_433.   Change your frequency back to the default 433.92 or lower.


I just get one reading, no more. If I run again I get no data, so it is not always work.

Are you doing all short tests?   The rtl-sdr frequency will drift during the warm up of the oscillator.



New measure with SDRSHARP from 1 meter distance:


From 2-3 meter:


My current antenna is a 16cm wire:



Ah, Get a USB- A extension cable with a ferrite,   Get the rtl-sdr receiver far away from the noise generated by the computer or RPi.



Does this info helps? If not, could you please show me how I can save captures what you said?

Use -a -t.   It's documented in the README https://github.com/merbanan/rtl_433/blob/master/README.md


Hope this helps
--Rob



On Saturday, January 30, 2016 at 12:54:24 AM UTC+1, David Woodhouse wrote:
On Fri, 2016-01-29 at 11:56 -0800, Adrián Mihálko wrote:
>
> I am trying to use rtl_433 on a RPi with my Hama Nano receiver. It
> works, but for a few centimeters only.
>
> I decided to buy a 433Mhz antenna like this:
>
> http://www.ebay.com/itm/GSM-GPRS-Antenna-433Mhz-3dbi-cable-SMA-male-M
> agnetic-base-for-Ham-1-5M-RG174-/330915811011
>
> But it does not helps at all.
>
> Any other suggestions?

Save some captures when it just stops working, let us take a look...

--
dwmw2


--
You received this message because you are subscribed to the Google Groups "rtl_433" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtl_433+u...@googlegroups.com.
To post to this group, send email to rtl...@googlegroups.com.
Visit this group at https://groups.google.com/group/rtl_433.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rtl_433/03df37cc-5c71-4425-bc5c-06798dab473b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

David Woodhouse

unread,
Jan 30, 2016, 1:03:43 PM1/30/16
to Robert Terzi, rtl...@googlegroups.com
On Sat, 2016-01-30 at 12:48 -0500, Robert Terzi wrote:
>
> 1. try runs with -a -t to collect gfileNNN.data samples as David
> suggested.  You will not get any decodes run running in -a mode.  You
> will get files that can be played back with rtl_433 -r as well as
> inspected with Audacity or something similar.

FWIW I keep meaning to do something about that. I often leave it
running with this hack so it *does* decode in -a mode, while also
storing captures:

--- a/src/rtl_433.c
+++ b/src/rtl_433.c
@@ -629,7 +629,7 @@ static void rtlsdr_callback(unsigned char *iq_buf, uint32_t len, void *ctx) {
 
  if (demod->analyze || (demod->out_file == stdout)) { // We don't want to decode devices when outputting to stdout
  pwm_analyze(demod, demod->am_buf, len / 2);
- } else {
+ } /*else*/ {
  // Loop through all demodulators for all samples (CPU intensive!)
  for (i = 0; i < demod->r_dev_num; i++) {
  switch (demod->r_devs[i]->modulation) {


What I actually want, though, is for it to store only the captures it
*didn't* manage to decode. Unless anyone objects to that on principle,
I'll put together a patch for it...

--
dwmw2

Robert Terzi

unread,
Jan 30, 2016, 2:59:40 PM1/30/16
to David Woodhouse, rtl...@googlegroups.com
On 1/30/2016 1:03 PM, David Woodhouse wrote:

> FWIW I keep meaning to do something about that. I often leave it
> running with this hack so it *does* decode in -a mode, while also
> storing captures:

So, I'm wondering if that really is a hack or not? What are the downsides
of removing that modality?

Any unexpected side effects when also using -t?


> What I actually want, though, is for it to store only the captures it
> *didn't* manage to decode. Unless anyone objects to that on principle,
> I'll put together a patch for it...

Yes, I've been thinking about that/desiring the functionality to optionally
run the analyzer and/or capture files for signals that didn't decode.

Related, I was thinking about starting to capture some stats in the
decoders for number of signals decoded, number of times calls,
number of rejected decodes. It would be useful to have access to that
data when running regression tests.

--Rob

David Woodhouse

unread,
Jan 30, 2016, 3:04:29 PM1/30/16
to Robert Terzi, rtl...@googlegroups.com
On Sat, 2016-01-30 at 14:59 -0500, Robert Terzi wrote:
> On 1/30/2016 1:03 PM, David Woodhouse wrote:
>
> > FWIW I keep meaning to do something about that. I often leave it
> > running with this hack so it *does* decode in -a mode, while also
> > storing captures:
>
> So, I'm wondering if that really is a hack or not?  What are the downsides
> of removing that modality?
>
> Any unexpected side effects when also using -t?

None that I've noticed; only the expected and desired effects.

--
dwmw2

Benjamin Larsson

unread,
Feb 1, 2016, 9:29:23 AM2/1/16
to rtl...@googlegroups.com
Patch welcome. Make that the default but add a command line override.

/Benjamin

David Woodhouse

unread,
Feb 1, 2016, 3:29:04 PM2/1/16
to Benjamin Larsson, rtl...@googlegroups.com
On Mon, 2016-02-01 at 15:29 +0100, Benjamin Larsson wrote:
>
> Patch welcome. Make that the default but add a command line override.

Hm, not quite working as intended. There is a synchronisation issue
between the decoders and pwm_analyze(), where the decoder actually
emits an event in the rtlsdr_callback() invocation *before*
pwm_analyze() dumps the signal to a file.

So the simple hack to prevent pwm_analyze() from dumping to a file if
any decoders worked... doesn't always do its job.

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 6376b88..15f9f52 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -34,7 +34,7 @@ if(CMAKE_COMPILER_IS_GNUCC AND NOT WIN32)
     ADD_DEFINITIONS(-Wextra)
     ADD_DEFINITIONS(-Wno-unused)
     ADD_DEFINITIONS(-Wsign-compare)
-    ADD_DEFINITIONS(-g3 -O0)
+    ADD_DEFINITIONS(-g3 -O2)
     ADD_DEFINITIONS(-std=gnu99)
     #http://gcc.gnu.org/wiki/Visibility
     add_definitions(-fvisibility=hidden)
diff --git a/src/devices/emontx.c b/src/devices/emontx.c
index 3a090ab..fb9565a 100644
--- a/src/devices/emontx.c
+++ b/src/devices/emontx.c
@@ -39,6 +39,7 @@ static int emontx_callback(bitbuffer_t *bitbuffer) {
  bitrow_t *bb = bitbuffer->bb;
  unsigned bitpos = 0;
  unsigned bits = bitbuffer->bits_per_row[0];
+ int events = 0;
 
  // Search for only 22 bits to cope with inverted frames and
  // the missing final preamble bit with RFM69 transmissions.
@@ -125,8 +126,9 @@ static int emontx_callback(bitbuffer_t *bitbuffer) {
   words[10] == 3000 ? NULL : "temp6_C", "", DATA_FORMAT, "%.1f", DATA_DOUBLE, (double)words[10] / 10.0,
   NULL);
  data_acquired_handler(data);
+ events++;
  }
- return 0;
+ return events;
 }
 
 static char *output_fields[] = {
diff --git a/src/devices/oil_watchman.c b/src/devices/oil_watchman.c
index e6913cf..c87f3f1 100644
--- a/src/devices/oil_watchman.c
+++ b/src/devices/oil_watchman.c
@@ -33,6 +33,7 @@ static int oil_watchman_callback(bitbuffer_t *bitbuffer) {
  data_t *data;
  unsigned bitpos = 0;
  bitbuffer_t databits = {0};
+ int events = 0;
 
  local_time_str(0, time_str);
 
@@ -91,8 +92,9 @@ static int oil_watchman_callback(bitbuffer_t *bitbuffer) {
   "depth", "", DATA_INT, depth,
   NULL);
  data_acquired_handler(data);
+ events++;
  }
- return 0;
+ return events;
 };
 
 static char *output_fields[] = {
diff --git a/src/rtl_433.c b/src/rtl_433.c
index 0771fda..1b23a24 100644
--- a/src/rtl_433.c
+++ b/src/rtl_433.c
@@ -73,6 +73,7 @@ struct dm_state {
 
     /* Signal grabber variables */
     int signal_grabber;
+ int grab_all;
     int8_t* sg_buf;
     int sg_index;
     int sg_len;
@@ -110,7 +111,8 @@ void usage(r_device *devices) {
             "\t[-q] Quiet mode, suppress non-data messages\n"
             "\t[-W] Overwrite mode, disable checks to prevent files from being overwritten\n"
             "\t= File I/O options =\n"
-            "\t[-t] Test signal auto save. Use it together with analyze mode (-a -t). Creates one file per signal\n"
+            "\t[-t] Test signal auto save. Use it together with analyze mode (-a -t). Creates one file per undecoded signal\n"
+ "\t[-T] Test signal auto save. Like -t but saves all signals, even successfully decoded ones\n"
             "\t\t Note: Saves raw I/Q samples (uint8 pcm, 2 channel). Preferred mode for generating test files\n"
             "\t[-r <filename>] Read data from input file instead of a receiver\n"
             "\t[-m <mode>] Data file mode for input / output file (default: 0)\n"
@@ -466,7 +468,7 @@ static void classify_signal() {
 
 };
 
-static void pwm_analyze(struct dm_state *demod, int16_t *buf, uint32_t len) {
+static int pwm_analyze(struct dm_state *demod, int16_t *buf, uint32_t len, int grab) {
     unsigned int i;
     int32_t threshold = (demod->level_limit ? demod->level_limit : DEFAULT_LEVEL_LIMIT); // Fix for auto level
 
@@ -513,7 +515,7 @@ static void pwm_analyze(struct dm_state *demod, int16_t *buf, uint32_t len) {
                 classify_signal();
 
                 signal_pulse_counter = 0;
-                if (demod->sg_buf) {
+                if (demod->sg_buf && grab) {
                     int start_pos, signal_bszie, wlen, wrest = 0, sg_idx, idx;
                     char sgf_name[256] = {0};
                     FILE *sgfp;
@@ -569,17 +571,17 @@ static void pwm_analyze(struct dm_state *demod, int16_t *buf, uint32_t len) {
 
 
     }
-    return;
+    return 0;
 
 err:
-    fprintf(stderr, "To many pulses detected, probably bad input data or input parameters\n");
-    return;
+    fprintf(stderr, "Too many pulses detected, probably bad input data or input parameters\n");
+    return 0;
 }
 
 
 static void rtlsdr_callback(unsigned char *iq_buf, uint32_t len, void *ctx) {
     struct dm_state *demod = ctx;
-    int i;
+    int i, events = 0;
 
  if (do_exit || do_exit_async)
  return;
@@ -617,9 +619,7 @@ static void rtlsdr_callback(unsigned char *iq_buf, uint32_t len, void *ctx) {
  }
  }
 
- if (demod->analyze || (demod->out_file == stdout)) { // We don't want to decode devices when outputting to stdout
- pwm_analyze(demod, demod->am_buf, len / 2);
- } else {
+ if (demod->out_file != stdout) { // We don't want to decode devices when outputting to stdout
  // Detect a package and loop through demodulators with pulse data
  int package_type = 1; // Just to get us started
  while(package_type) {
@@ -629,25 +629,25 @@ static void rtlsdr_callback(unsigned char *iq_buf, uint32_t len, void *ctx) {
  for (i = 0; i < demod->r_dev_num; i++) {
  switch (demod->r_devs[i]->modulation) {
  case OOK_PULSE_PCM_RZ:
- pulse_demod_pcm(&demod->pulse_data, demod->r_devs[i]);
+ events += pulse_demod_pcm(&demod->pulse_data, demod->r_devs[i]);
  break;
  case OOK_PULSE_PPM_RAW:
- pulse_demod_ppm(&demod->pulse_data, demod->r_devs[i]);
+ events += pulse_demod_ppm(&demod->pulse_data, demod->r_devs[i]);
  break;
  case OOK_PULSE_PWM_PRECISE:
- pulse_demod_pwm_precise(&demod->pulse_data, demod->r_devs[i]);
+ events += pulse_demod_pwm_precise(&demod->pulse_data, demod->r_devs[i]);
  break;
  case OOK_PULSE_PWM_RAW:
- pulse_demod_pwm(&demod->pulse_data, demod->r_devs[i]);
+ events += pulse_demod_pwm(&demod->pulse_data, demod->r_devs[i]);
  break;
  case OOK_PULSE_PWM_TERNARY:
- pulse_demod_pwm_ternary(&demod->pulse_data, demod->r_devs[i]);
+ events += pulse_demod_pwm_ternary(&demod->pulse_data, demod->r_devs[i]);
  break;
  case OOK_PULSE_MANCHESTER_ZEROBIT:
- pulse_demod_manchester_zerobit(&demod->pulse_data, demod->r_devs[i]);
+ events += pulse_demod_manchester_zerobit(&demod->pulse_data, demod->r_devs[i]);
  break;
  case OOK_PULSE_CLOCK_BITS:
- pulse_demod_clock_bits(&demod->pulse_data, demod->r_devs[i]);
+ events += pulse_demod_clock_bits(&demod->pulse_data, demod->r_devs[i]);
  break;
  // FSK decoders
  case FSK_PULSE_PCM:
@@ -673,10 +673,10 @@ static void rtlsdr_callback(unsigned char *iq_buf, uint32_t len, void *ctx) {
  case OOK_PULSE_CLOCK_BITS:
  break;
  case FSK_PULSE_PCM:
- pulse_demod_pcm(&demod->fsk_pulse_data, demod->r_devs[i]);
+ events += pulse_demod_pcm(&demod->fsk_pulse_data, demod->r_devs[i]);
  break;
  case FSK_PULSE_PWM_RAW:
- pulse_demod_pwm(&demod->fsk_pulse_data, demod->r_devs[i]);
+ events += pulse_demod_pwm(&demod->fsk_pulse_data, demod->r_devs[i]);
  break;
  default:
  fprintf(stderr, "Unknown modulation %d in protocol!\n", demod->r_devs[i]->modulation);
@@ -687,6 +687,10 @@ static void rtlsdr_callback(unsigned char *iq_buf, uint32_t len, void *ctx) {
  }
  }
  }
+ if (demod->analyze || (demod->out_file == stdout)) {
+ printf("analyze, events %d\n", events);
+ pwm_analyze(demod, demod->am_buf, len / 2, demod->grab_all || !events);
+ }
 
  if (demod->out_file) {
  uint8_t* out_buf = iq_buf; // Default is to dump IQ samples
@@ -787,7 +791,7 @@ int main(int argc, char **argv) {
 
     demod->level_limit = DEFAULT_LEVEL_LIMIT;
 
-    while ((opt = getopt(argc, argv, "x:z:p:DtaAqm:r:l:d:f:g:s:b:n:SR:F:C:W")) != -1) {
+    while ((opt = getopt(argc, argv, "x:z:p:DtTaAqm:r:l:d:f:g:s:b:n:SR:F:C:W")) != -1) {
         switch (opt) {
             case 'd':
                 dev_index = atoi(optarg);
@@ -826,6 +830,9 @@ int main(int argc, char **argv) {
             case 't':
                 demod->signal_grabber = 1;
                 break;
+            case 'T':
+                demod->signal_grabber = demod->grab_all = 1;
+                break;
             case 'm':
                 demod->debug_mode = atoi(optarg);
                 break;
--
dwmw2

Benjamin Larsson

unread,
Feb 1, 2016, 4:40:30 PM2/1/16
to David Woodhouse, rtl...@googlegroups.com
On 02/01/2016 09:28 PM, David Woodhouse wrote:
> On Mon, 2016-02-01 at 15:29 +0100, Benjamin Larsson wrote:
>>
>> Patch welcome. Make that the default but add a command line override.
>
> Hm, not quite working as intended. There is a synchronisation issue
> between the decoders and pwm_analyze(), where the decoder actually
> emits an event in the rtlsdr_callback() invocation *before*
> pwm_analyze() dumps the signal to a file.
>
> So the simple hack to prevent pwm_analyze() from dumping to a file if
> any decoders worked... doesn't always do its job.

I don't really follow here, can you elaborate or point to an example ?

>
> diff --git a/CMakeLists.txt b/CMakeLists.txt
> index 6376b88..15f9f52 100644
> --- a/CMakeLists.txt
> +++ b/CMakeLists.txt
> @@ -34,7 +34,7 @@ if(CMAKE_COMPILER_IS_GNUCC AND NOT WIN32)
> ADD_DEFINITIONS(-Wextra)
> ADD_DEFINITIONS(-Wno-unused)
> ADD_DEFINITIONS(-Wsign-compare)
> - ADD_DEFINITIONS(-g3 -O0)
> + ADD_DEFINITIONS(-g3 -O2)
> ADD_DEFINITIONS(-std=gnu99)
> #http://gcc.gnu.org/wiki/Visibility
> add_definitions(-fvisibility=hidden)

Ok, maybe -O3 instead.

> static char *output_fields[] = {
> diff --git a/src/rtl_433.c b/src/rtl_433.c
> index 0771fda..1b23a24 100644
> --- a/src/rtl_433.c
> +++ b/src/rtl_433.c
> @@ -73,6 +73,7 @@ struct dm_state {
>
> /* Signal grabber variables */
> int signal_grabber;
> + int grab_all;
> int8_t* sg_buf;
> int sg_index;
> int sg_len;
> @@ -110,7 +111,8 @@ void usage(r_device *devices) {
> "\t[-q] Quiet mode, suppress non-data messages\n"
> "\t[-W] Overwrite mode, disable checks to prevent files from being overwritten\n"
> "\t= File I/O options =\n"
> - "\t[-t] Test signal auto save. Use it together with analyze mode (-a -t). Creates one file per signal\n"
> + "\t[-t] Test signal auto save. Use it together with analyze mode (-a -t). Creates one file per undecoded signal\n"
> + "\t[-T] Test signal auto save. Like -t but saves all signals, even successfully decoded ones\n"
> "\t\t Note: Saves raw I/Q samples (uint8 pcm, 2 channel). Preferred mode for generating test files\n"
> "\t[-r <filename>] Read data from input file instead of a receiver\n"
> "\t[-m <mode>] Data file mode for input / output file (default: 0)\n"

Ok

> @@ -466,7 +468,7 @@ static void classify_signal() {
>
> };
>
> -static void pwm_analyze(struct dm_state *demod, int16_t *buf, uint32_t len) {
> +static int pwm_analyze(struct dm_state *demod, int16_t *buf, uint32_t len, int grab) {
> unsigned int i;
> int32_t threshold = (demod->level_limit ? demod->level_limit : DEFAULT_LEVEL_LIMIT); // Fix for auto level
>
> @@ -513,7 +515,7 @@ static void pwm_analyze(struct dm_state *demod, int16_t *buf, uint32_t len) {
> classify_signal();
>
> signal_pulse_counter = 0;
> - if (demod->sg_buf) {
> + if (demod->sg_buf && grab) {
> int start_pos, signal_bszie, wlen, wrest = 0, sg_idx, idx;
> char sgf_name[256] = {0};
> FILE *sgfp;

Ok

> @@ -569,17 +571,17 @@ static void pwm_analyze(struct dm_state *demod, int16_t *buf, uint32_t len) {
>
>
> }
> - return;
> + return 0;
>
> err:
> - fprintf(stderr, "To many pulses detected, probably bad input data or input parameters\n");
> - return;
> + fprintf(stderr, "Too many pulses detected, probably bad input data or input parameters\n");
> + return 0;

Ok
Use fprintf.

> + pwm_analyze(demod, demod->am_buf, len / 2, demod->grab_all || !events);
> + }
>
> if (demod->out_file) {
> uint8_t* out_buf = iq_buf; // Default is to dump IQ samples
> @@ -787,7 +791,7 @@ int main(int argc, char **argv) {
>
> demod->level_limit = DEFAULT_LEVEL_LIMIT;
>
> - while ((opt = getopt(argc, argv, "x:z:p:DtaAqm:r:l:d:f:g:s:b:n:SR:F:C:W")) != -1) {
> + while ((opt = getopt(argc, argv, "x:z:p:DtTaAqm:r:l:d:f:g:s:b:n:SR:F:C:W")) != -1) {
> switch (opt) {
> case 'd':
> dev_index = atoi(optarg);
> @@ -826,6 +830,9 @@ int main(int argc, char **argv) {
> case 't':
> demod->signal_grabber = 1;
> break;
> + case 'T':
> + demod->signal_grabber = demod->grab_all = 1;
> + break;
> case 'm':
> demod->debug_mode = atoi(optarg);
> break;
>

Ok



David Woodhouse

unread,
Feb 1, 2016, 5:16:32 PM2/1/16
to Benjamin Larsson, rtl...@googlegroups.com
On Mon, 2016-02-01 at 22:40 +0100, Benjamin Larsson wrote:
>
> > +     if (demod->analyze || (demod->out_file == stdout)) {
> > +             printf("analyze, events %d\n", events);
>
> Use fprintf.

That's just a debugging hack for demonstration. When my hack works
nicely, the output looks like this...

analyze, events 0
analyze, events 0
analyze, events 0
analyze, events 0
analyze, events 0
{"time" : "2016-02-01 22:14:08", "model" : "emonTx", "node" : 8, "ct1" : 1001, "ct2" : 0, "ct3" : 919, "ct4" : 58, "Vrms/batt" : 240.320000, "pulse" : 374772}
analyze, events 1
*** signal_start = 50620940, signal_end = 50646975
signal_len = 26035,  pulses = 1
Distance coding: Pulse length 6034

Short distance: 1000000, long distance: 0, packet distance: 0

p_limit: 6034
bitbuffer:: Number of rows: 0 
analyze, events 0
analyze, events 0

That is, there's one call to rtlsdr_callback() during which the emontx
driver manages to decode a packet, and the pwm_analyze() *would* have
saved a sample except that 'events==1' so it didn't. This is how it was
intended to work.

However, other times it looks like this...

analyze, events 0
analyze, events 0
analyze, events 0
{"time" : "2016-02-01 22:13:58", "model" : "emonTx", "node" : 8, "ct1" : 942, "ct2" : 1, "ct3" : 866, "ct4" : 57, "Vrms/batt" : 240.440000, "pulse" : 374770}
analyze, events 1
analyze, events 0
*** signal_start = 40714728, signal_end = 40740762
signal_len = 26034,  pulses = 1
Distance coding: Pulse length 6033

Short distance: 1000000, long distance: 0, packet distance: 0

p_limit: 6033
bitbuffer:: Number of rows: 0 
signal_bszie = 131072  -      sg_index = 0
start_pos    = 2707250  -   buffer_size = 3145728
*** Saving signal to file gfile036.data
*** Writing data from 2707250, len 131072
analyze, events 0
analyze, events 0

In this case, pwm_analyze() didn't save the sample until the *next*
invocation of rtlsdr_callback(), *after* the emontx driver had decoded
the packet.


--
dwmw2

Tommy Vestermark

unread,
Feb 2, 2016, 2:03:27 PM2/2/16
to rtl_433, ba...@ludd.ltu.se
Hi,

Regarding synchronization, pwm_analyze() and pulse_detect_package() have different criteria for detecting signals, so they will never be completely synchronized. If needed we could make a "save_test_signal()" function invoked when pulse_detect_package() has got a catch. At that point pwm_analyze() probably becomes redundant.. or?

/Tommy

Benjamin Larsson

unread,
Feb 2, 2016, 2:39:59 PM2/2/16
to Tommy Vestermark, rtl_433
Right now we have 2 analyze modes. That is one too many. So when -A has
all the features of -a we can get rid of the -a code.

MvH
Benjamin Larsson

David Woodhouse

unread,
Feb 2, 2016, 2:51:32 PM2/2/16
to Tommy Vestermark, rtl_433, ba...@ludd.ltu.se
That's the *opposite* of what we want. In this case, I wanted to save
the signals when a signal occurred but *wasn't* decoded.

I'd settle for *that* mode being predicated on pulse_detect_package()
triggering but no successful decodes. Although you've previously
observed that the independence of pwm_analyze() is a *benefit* for
keeping the decoders honest, I think we could sacrifice it in this case
for this feature.

--
dwmw2

Reply all
Reply to author
Forward
0 new messages