Feature request? Having it stop

[Alan Corey]

I'd like to run this from a cron job, but not 24 hours.  I'd like to be able to record the BBC Newshour once a day (same dongle) then go back to logging temperatures.  Stopping at a preset time, running for a preset duration or number of readings would all work.  Or I could rig something to kill it but that's messy.

Running on a Raspberry Pi 3B monitoring an Oregon Scientific EMR211, works fine.  I mentioned this program in the Raspberry Pi forums.

[Benjamin Larsson]

On 07/26/2016 05:36 AM, Alan Corey wrote:
> I'd like to run this from a cron job, but not 24 hours. I'd like to be
> able to record the BBC Newshour once a day (same dongle) then go back to
> logging temperatures. Stopping at a preset time, running for a preset
> duration or number of readings would all work. Or I could rig something
> to kill it but that's messy.

This sounds like a perfect task for a cron job. But if someone writes a
clean patch for duration based run time I will accept it. Meanwhile use
a simple cron tab for your need.

MvH
Benjamin Larsson

[Alan Corey]

The problem is that there's no programatic way to stop rtl_433. When
I record with rtl_fm and pipe it through sox I use the trim option to
sox to stop it after a preset time. When I record RF background
levels with rtl_power I use the -e exit timer option.

About my only options here are to use something like pkill to kill the
process. Or write something which does a popen() or system() to
format and store the rtl_433 output, and also has an exit timer option
which would kill the rtl_433. Or muck around in your source and add
it there.

Unrelated, but can rtl_433 do anything with the output from a simple
FS1000A 433 MHz transmitter module like at
http://www.gearbest.com/transmitters-receivers-module/pp_225981.html ?
They're cheap enough (under $1) that I ordered one to experiment with
anyway. If all goes well I'd like to feed a varying rate pulse train
from a homebrew anemometer through it. It has a spinning disk with 60
holes that passes between an LED and a phototransistor. I have
calibration data that relates pulse rate to MPH, which is linear.

> --
> You received this message because you are subscribed to a topic in the
> Google Groups "rtl_433" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/rtl_433/kbxpKmTp9oM/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> rtl_433+u...@googlegroups.com.
> To post to this group, send an 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/57991E4D.2040201%40ludd.ltu.se.
> For more options, visit https://groups.google.com/d/optout.
>


--
Credit is the root of all evil. - AB1JX

[Benjamin Larsson]

On 07/28/2016 12:01 AM, Alan Corey wrote:
> The problem is that there's no programatic way to stop rtl_433. When
> I record with rtl_fm and pipe it through sox I use the trim option to
> sox to stop it after a preset time. When I record RF background
> levels with rtl_power I use the -e exit timer option.
>
> About my only options here are to use something like pkill to kill the
> process. Or write something which does a popen() or system() to
> format and store the rtl_433 output, and also has an exit timer option
> which would kill the rtl_433.

Yes, you have to use something like killall -9 rtl_433 in a cron tab.

> Or muck around in your source and add
> it there.

Excellent, make the code awesome and send a patch.

>
> Unrelated, but can rtl_433 do anything with the output from a simple
> FS1000A 433 MHz transmitter module like at
> http://www.gearbest.com/transmitters-receivers-module/pp_225981.html ?
> They're cheap enough (under $1) that I ordered one to experiment with
> anyway. If all goes well I'd like to feed a varying rate pulse train
> from a homebrew anemometer through it. It has a spinning disk with 60
> holes that passes between an LED and a phototransistor. I have
> calibration data that relates pulse rate to MPH, which is linear.
>

It will be able to analyze the signal and demodulate it. But the
architecture is built to handle short signals with a fixed set of pulses
so you'd need to hack the code a bit for it to work the way you want.
And please follow the duty cycle recommendations for the 433MHz ISM
band. There are others transmitting data at the same time as you.

MvH
Benjamin Larsson

[Alan Corey]

Never mind, stopping is already built in, I just didn't notice it before.

  [-T] specify number of seconds to run

I was looking at how to make it work as much like the -e option of rtl_power as possible, and the first thing I ran into was the variable do_exit, then stop_time.  So yup, read a time_t, add the desired duration, then keep checking every time through some main loop whether it's that time yet, set do_exit if it is.

Your -S for sync mode is different from rtl_sdr's though, there it relates to sync mode of the USB connection.  In OpenBSD async USB doesn't work, so there are patches in the OpenBSD ports to add sync mode to the programs that didn't have it.  Unfortunately that was done in 2013 and it's never been updated, so if you install by the book in OpenBSD you get an old version that's missing more recent things like rtl_power, rtl_tcp, rtl_adsb.

rtl_433 runs on OpenBSD though, I've been monitoring temperature with it for 2 days.