Re-transmitting

[Peter Drozda]

Hi guys,

I was thinking..

Since rlt_433 can save received signals e.g. in .cu8 format - although I'm not aware of details of the specification, but since it is possible to visualize the signal from .cu8,

it should be also possible to send this signal by simple/cheap rf transmitter - at least in case of ASK. I guess, there should be enough information about timing and pulses..

Have you ever heard of any project which would be dealing with something like that?

With such possibility, it woule be possible to build quite powerfull gateway with DVB-T Dongle + Cheap ASK transmitter + e.g. Raspberry Pi...

If there is no such product... is there at least some library which would parse .cu8 and/or any other output from rtl_433 which would serve as a base for re-transmition of the signal?

Thanks,

Peter

[Christian Zuckschwerdt]

In principle https://github.com/zuckschwerdt/tx_tools/ should work. My LimeSDRs are broken though, and I can't test.

If you want to use some "cheap ASK transmitter" you need to AM decode the signal first. Use rtl_433 with `-w file.am.s16`, but you'd still need to recover timing. Look at the VCD output (`-w file.vcd`) -- that should be the most "direct" way. Perhaps code a universal "vcd_transmit"?

[ToCHo]

I am currently developing a GUI featured prototyping tool which extends an rtl_433 based library with TX functionality.
Opening an retransmitting cu8 files already works for OOK based protocols (FSK might follow later).
It needs some more finishing before I'll upload a first version onto GitHub. Also, the first release will be for Windows, a Linux GUI ist also planned for the future. See my post in the VS17 thread for some more information and a preview screenshot.

[Peter Drozda]

Hi Tobias,

Very interesting project..

But I would be quite afraid to use such Vga devices as transmitters because of those harmonics??? Or is it usable?

Thanks

--
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/b2gUT1M-tPk/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/0587fd9b-4f92-457b-9c5a-9bb647ee5e3d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[ToCHo]

You're right, one should not simply attach powerful antennas or even amplifiers to it without inserting a filter blocking all unwanted frequencies. So for a productive use some precautions are needed.

However for some quick, short-distance prototyping tests in a controlled environment I consider this a fancy cheap and handy option. In some cases you don't even need an antenna/wire at all, just place the receiving device near the VGA adapter.

Sure, for productive use I would also recommend other solutions...

[ToCHo]

By the way, it is the same situation with some other low cost solutions, for example the popular rpitx...

[Peter Drozda]

Yes.. you are right..

I'm basically looking for affordable and flexible solution for hpme automation..

I thought that cheap OOK transmitters are simple and straightforward to serve this purpose, if one would be able to extract exact timing e.g. from .cu8 or any other output of rtl_433..

Then I can imagine simple Rest API extension for rtl_433 where one would be able to start service either in standard receiver mode e.g. forwarding to mqtt or in "learning mode" where received signals would be stored and later streamed by other tool via ook transmitter.. in the simplest scenario transmitter would be connected to raspberry pi gpio...

The hw part could be somehow abstracted to kind of driver..

I need to study the stuff suggested by Christian..

Peter

On Monday, October 8, 2018, ToCHo <tobia...@gmail.com> wrote:

--
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/b2gUT1M-tPk/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/730f5807-ea8f-435e-a1ef-094cb582a65d%40googlegroups.com.

[J Dow]

On Monday, October 8, 2018 at 8:01:10 AM UTC-7, Christian Zuckschwerdt wrote:

In principle https://github.com/zuckschwerdt/tx_tools/ should work. My LimeSDRs are broken though, and I can't test.

If you want to use some "cheap ASK transmitter" you need to AM decode the signal first. Use rtl_433 with `-w file.am.s16`, but you'd still need to recover timing. Look at the VCD output (`-w file.vcd`) -- that should be the most "direct" way. Perhaps code a universal "vcd_transmit"?

For those interested in transmitting here is a really nice wall chart to use if you want to find who might send people knocking at your door with official looking paper in their hands: https://www.ntia.doc.gov/files/ntia/publications/january_2016_spectrum_wall_chart.pdf

Consider harmonics when building the transmitter. They radiate nicely, particularly odd harmonics. (Although loaded antennas, coil at the base, may radiate even harmonics quite effectively, too, in some cases.) Keep the power down as low as you can go and do the required job. Unless you actually interfere with somebody the FCC is very very likely to ignore you completely. But if you interfere with military, commercial public safety, or satellite downlinks you're probably safe. Pick your enemies carefully.

ToCho, I noticed a comment in one of your repositories about running TX off 12 V to get more power. That is unwise considering the above and both the primary and secondary owners of 433.92 MHz. (Expect interference from RADIOLOCATION (primary - Radars) and Amateur users.) It would take a particularly stinky feeling ham to start using, legally, high power (50W EIRP or so) on 433.92. All manner of quite broad band transmissions are allowed in that frequency range, though. So some ham running wide band TV or some other wide mode might cause problems. And if you caused problems to the ham you could be shut down.

I guess the general rule is "be nice". That includes using minimum necessary power. Fortunately the 434 MHz is not used much. The harmonics, though, include some sensitive toes.

{^_-}   Joanne

[ToCHo]

> ToCho, I noticed a comment in one
> of your repositories about running
> TX off 12 V to get more power.

I'm quite sure I've never written anything like this. My current repositories are only forks of existing open source projects like rtl_433, librtlsdr and osmo-fl2k. There's so self-written code present until now.
Probably you found a comment originating from these projects, I can't check right now.

[J Dow]

That's entirely possible. Sorry if I offended you.

{o.o}

[Christian Zuckschwerdt]

Peter, if you are not looking for real-time processing but learn-and-replay then you might want to compress the input to a simple list of timings. I.e. don't store and process the IQ files (.cu8) but the demodulated ASK output. Maybe have a look at the VCD file. If there is some consensus on how to store an ASK/FSK signal for replay with OOK or CC1101, … then we could implement that as rtl_433 output.

[Peter Drozda]

Hi Christian,

Thanks for the hint :) .vcd looks promising for my purposes.. I'm not yet fully familiar with it, but I generated few samples and I'm going to analyze them..

Btw, I see the VCD branch is already backintegrated :) Thanks for that.

Best regards, 

Peter

On Tue, Oct 9, 2018 at 10:18 AM Christian Zuckschwerdt <chri...@zuckschwerdt.org> wrote:

Peter, if you are not looking for real-time processing but learn-and-replay then you might want to compress the input to a simple list of timings. I.e. don't store and process the IQ files (.cu8) but the demodulated ASK output. Maybe have a look at the VCD file. If there is some consensus on how to store an ASK/FSK signal for replay with OOK or CC1101, … then we could implement that as rtl_433 output.

--

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/b2gUT1M-tPk/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 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/6deded5d-1621-4cd9-81d3-9eded98c15a3%40googlegroups.com.

[Peter Drozda]

I'm probably doing something wrong..

I tried e.g.

rtl_433 -F json -R 3 -w prologue.vcd

and it generated the file as attached..

It is quite strange, because when I try to analyze the gaps, I always get cca 4000us and cca 450 us difference over and over again ..

Somehow it does not make sense to me, but maybe I'm just interpreting it the wrong way :(

What am I doing wrong?

Thanks.

[Christian Zuckschwerdt]

Something went wrong creating the file. The zero-characters (^@) should be quotes (' and "). You can also take a .cu8 and convert it: rtl_433 -r file.cu8 -w file.vcd

 

[Christian Zuckschwerdt]

The actual transmission starts at 21s in and is plain PPM (pulses of fixed widht, gaps vary):

(a bit of preamble and 5 repeats)

[Peter Drozda]

... hmmm... it should be really pretty straightforward to write a parser with e.g. gpio output for cheap ook transmitter - to start with.. now I just need to find some time :)) If implemented general enough including hw abstraction, it could be used as a basis for interesting framework which would be complementary to rtl_433...

I will share my results if I have any..

Thanks a lot!

--

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/b2gUT1M-tPk/unsubscribe.

To unsubscribe from this group and all its topics, send an email to rtl_433+unsubscribe@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/acdc5d02-6a9a-4a14-bf60-4bff90e503c3%40googlegroups.com.

[Peter Drozda]

btw.. even when I use   rtl_433 -r file.cu8 -w file.vcd it still creates the .vcd with ^@ instead of ' ...

Maybe it is somhow specific to environment.. I'm running it on raspberry pi..

On Tue, Oct 9, 2018 at 10:08 PM Peter Drozda <pdr...@gmail.com> wrote:

... hmmm... it should be really pretty straightforward to write a parser with e.g. gpio output for cheap ook transmitter - to start with.. now I just need to find some time :)) If implemented general enough including hw abstraction, it could be used as a basis for interesting framework which would be complementary to rtl_433...

I will share my results if I have any..

Thanks a lot!

On Tuesday, October 9, 2018, Christian Zuckschwerdt <chri...@zuckschwerdt.org> wrote:

The actual transmission starts at 21s in and is plain PPM (pulses of fixed widht, gaps vary):

(a bit of preamble and 5 repeats)

--
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/b2gUT1M-tPk/unsubscribe.

To unsubscribe from this group and all its topics, send an email to rtl_433+u...@googlegroups.com.

[Christian Zuckschwerdt]

I'll take a look at the VCD writer, likely I have bug in there.

VCD is "human readable" (YMMV), but for a simpler parser on your end we could also come up with a similar but dumbed-down format.

[Peter Drozda]

Hi Christian,

thanks a lot..

Regarding simpler format.. I'm not sure.. I think it would be quite a waste of the resources on your side.. :)

Anyway, there would be some kind of time information and bit change.. basically when compared with .vcd there is only few garbage around in .vcd..

I've already started with the parser sketch, but I'm progressing veeery slowly, for many years I'm working only in java and getting back to c is reaaaaaly painful :)

I'm too spoiled by java already :))

On Wed, Oct 10, 2018 at 3:45 PM Christian Zuckschwerdt <chri...@zuckschwerdt.org> wrote:

I'll take a look at the VCD writer, likely I have bug in there.

VCD is "human readable" (YMMV), but for a simpler parser on your end we could also come up with a similar but dumbed-down format.

--

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/b2gUT1M-tPk/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 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/2fc01e91-ff03-41da-a412-f05f1db5b121%40googlegroups.com.

[Peter Drozda]

So I have created something.. not yet tested, for sure buggy, but if anybody  is interested in re-transmission of .vcd files, you can have a look

https://github.com/pedroke/vcdt

any contribution is more than welcome.. Please take into account I'm not a C developer :)

[DXDIGGER]

Its to do with keyboard and country code settings if you press your shift and @ key you will get quotes. "

 try setting country and timezone to uk and keyboard layout

On Wednesday, 10 October 2018 08:41:53 UTC+1, Peter Drozda wrote:

btw.. even when I use   rtl_433 -r file.cu8 -w file.vcd it still creates the .vcd with ^@ instead of ' ...

Maybe it is somhow specific to environment.. I'm running it on raspberry pi..

On Tue, Oct 9, 2018 at 10:08 PM Peter Drozda <pdr...@gmail.com> wrote:

... hmmm... it should be really pretty straightforward to write a parser with e.g. gpio output for cheap ook transmitter - to start with.. now I just need to find some time :)) If implemented general enough including hw abstraction, it could be used as a basis for interesting framework which would be complementary to rtl_433...

I will share my results if I have any..

Thanks a lot!

On Tuesday, October 9, 2018, Christian Zuckschwerdt <chri...@zuckschwerdt.org> wrote:

The actual transmission starts at 21s in and is plain PPM (pulses of fixed widht, gaps vary):

(a bit of preamble and 5 repeats)

--
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/b2gUT1M-tPk/unsubscribe.

To unsubscribe from this group and all its topics, send an email to rtl...@googlegroups.com.