rtl-sdr.com

[marcomilazzo]

No description provided.

[marcomilazzo]

Hi
the soft is great and it works fine wit my old rtl-sdr
i tried now with rtl-sdr.com usb but i won't work
what can i do ?
marco

[xaelsouth]

Hi Marco,

not sure i know about what we are talking :).

Anyway, rtl-wmbus software makes no presumptions about hardware! All hardware setup things are done by rtl-sdr driver. rtl-wmbus works with 8 bit IQ interleaved streams only. You should try your rtl-sdr with any other software (like gqrx) to prove that your hardware works properly.

Xael

[marcomilazzo]

Hi Xael The hardware works fine I tried several softwares So it’s rtl-sdr driver that sets the radio parameters . perhaps it’s bandwidth The point is that with an old dvb-t usb stick all works fine With a new rtl-sdr.com usb stick I don’t have any reading Anyway can you please tell how to read the complete raw data even if possible with preamble? I need to see the packet with no decodification Thank’s a lot marco Da: Xael South [mailto:notifications@github.com] Inviato: domenica 27 gennaio 2019 15:03 A: xaelsouth/rtl-wmbus Cc: marco milazzo; Author Oggetto: Re: [xaelsouth/rtl-wmbus] rtl-sdr.com (#4) Hi Marco, not sure i know about what we are talking :). Anyway, rtl-wmbus software makes no presumptions about hardware! All hardware setup things are done by rtl-sdr driver. rtl-wmbus works with 8 bit IQ interleaved streams only. You should try your rtl-sdr with any other software (like gqrx) to prove that yout hardware works properly. Xael — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#4 (comment)> , or mute the thread <https://github.com/notifications/unsubscribe-auth/AO9-Y0JFGpgTDMZPbpsn8za0rLl7AvLFks5vHbGkgaJpZM4aOmfP> . <https://github.com/notifications/beacon/AO9-Y6CUDt1Usorc6KyPSOiTN3Q7xy1fks5vHbGkgaJpZM4aOmfP.gif>

…

--- Questa e-mail è stata controllata per individuare virus con Avast antivirus. https://www.avast.com/antivirus

[marcomilazzo]

hi
do you mow also how to set receiver parameters ?
i'm using Rtl-sdr and your cose
is there a tool ?
marco

[xaelsouth]

Hi Marco,

rtl-sdr driver sets just two things:

• the bandwidth as sample rate which is always set to 1.6MHz (bandwidth equal to sample rate because of complex signal)
• rx frequency which is normally set to 868.95MHz. You have to choose the frequency a little bit carefully, internal oscillator is not precise enough while receiving narrow band signals sent by wireless M-Bus devices. You can try to go with the frequency by 50kHz down or up and set that to 868.9MHz or 869.9MHz respectively. I have mentioned that in the readme.

Xael

[xaelsouth]

Reading the code you will find some places (fwrite(...)) where i wrote filtered and reconstructed signals to files.

[weetmuts]

I seem to be having the same problem. Bought a dongle from rtl-sdr.com
https://www.rtl-sdr.com/buy-rtl-sdr-dvb-t-dongles/

It works fine for listening to radio FM, using gqrx, but I does not work with
the command: rtl_sdr -f 868.9M -s 1600000 - 2>/dev/null | rtl_wmbus
which is permanently silent.

I have tried big antennas, small antennas and having the wmbustransmitter
10 cm from the reciving antenna, but no luck.

[marcomilazzo]

HI
USE
-f 868950000
it worhs now
ciao

[xaelsouth]

Hi weetmuts,

the stick you bought from www.rtl-sdr.com is a really nice thing because it has TCXO built in. As marcomilazzo already said, you have to specify the frequency in the command line more precisely even as 868.95M. Yes, a five after nine is a must in your case!

I have an old stick which has a 22ppm quartz built in. Because of that i had to set the frequency to 868.9M, just 50kHz under the standard frequency of 868.95M. Thas's all.

[weetmuts]

Yes, I have actually tested with 868.96M and it didnt work. But I am a bit suspicious of the antenna connector of the cable, the internal pin does not really protrude much, so it looks like it cannot make a connection. Perhaps the slightly defective connector works for lower FM radio frequencies but not for higher frequencies. I will investiage further.

Anyway @xaelsouth, I have added support for using rtl_wmbus to wmbusmeters (https://github.com/weetmuts/wmbusmeters) and it seems like at least one user of wmbusmeters have succesfully
gathered wmbus messages from his heat cost allocators through rtl_wmbus. (wmbusmeters/wmbusmeters#8) :-)

[kidpixo]

Anyway @xaelsouth, I have added support for using rtl_wmbus to wmbusmeters (https://github.com/weetmuts/wmbusmeters) and it seems like at least one user of wmbusmeters have succesfully
gathered wmbus messages from his heat cost allocators through rtl_wmbus. (weetmuts/wmbusmeters#8) :-)

Yes, indeed :-D

Great work @weetmuts !

[weetmuts]

Hi! I bought a cheap rtlsdr dongle instead. With it, I can actually receive messages from my Multical21 meter. But only every fourth message or so. It seems like, for the multical21, the physical hardware dongles has a much better receiption rate, almost 100%.

What do the numbers mean in the prefix? I am now using only C1;1;1; telegrams, is that
correct? Are C1;0;0, C1;1;0 or C1;0;1 probably broken telegrams?

Would it help you, if I made a recording of the rtlsdr output and a synched output from one of
my hardware dongles, to see if you can improve the reception rate for multical21?

[marcomilazzo]

hi
with rtl-sdr i receive corretly sensus meters
not one mistake
are you far from the meters?
marco

[weetmuts]

@marcomilazzo , yes but the Sensus is T1, and the Multical21 is C1.
I have tested 10 cm, 2 meters, 10 meters with a wall in between. Same results.

@xaelsouth would you like me to share a rtlsdr radio recording with the accompanying messages decoded by an imst dongle, as a kind of reference list of what should be in the recording?

[xaelsouth]

Hello weetmuts,

you are good with strings begin with C1;1 or with T1;1. The format behind a whole string is MODE;CRC_OK;3OUTOF6OK;TIMESTAMP;PACKET_RSSI;CURRENT_RSSI;LINK_LAYER_IDENT_NO;DATAGRAM_WITHOUT_CRC_BYTES.

3OUTOF6OK makes sense only with mode T1 and no sense with mode C1 (always set to 1).

C1 mode generally causes more problems regarding clock recovering because no channel coding is used. Channel coding would force transmitter to switch from 0 to 1 and back more often while sending that makes clock recovering by receiver easier on costs of datagram transmission time that takes longer.

Clock recovering algorithm (time square) implemented in rtl-wmbus could be replaced by any other known for to be good usable with wMbus (Mueller&Muller for example). Time square algorithm is fretful
regarding RX frequency. You could play with that shift the freq right or left and observe the rate of correct received datagrams - perhaps it would help.

I could give you a GnuRadio chart with wMbus-Receiver for experimenting with you dongle. But first i have to take a look at that, because it may be no more compatible with current GnuRadio version.

Xael

Hi! I bought a cheap rtlsdr dongle instead. With it, I can actually receive messages from my Multical21 meter. But only every fourth message or so. It seems like, for the multical21, the physical hardware dongles has a much better receiption rate, almost 100%.

What do the numbers mean in the prefix? I am now using only C1;1;1; telegrams, is that
correct? Are C1;0;0, C1;1;0 or C1;0;1 probably broken telegrams?

Would it help you, if I made a recording of the rtlsdr output and a synched output from one of
my hardware dongles, to see if you can improve the reception rate for multical21?

[xaelsouth]

Weetmuts,

could you share a rtlsdr radio recording? imst dongle is not relevant.

[weetmuts]

Here is a recording:
https://drive.google.com/open?id=1c78RsPDQjTMXKaKez3qtP5iZfwjWZgLm

By the way, I sometimes get lines that look like the one below, into wmbusmeters, ie there are two ;0x
on the line. It seems like the default code of rtl_wmbus would not output it that way?
But perhaps the user has accidentally enabe the "#if 0" to printout the message with the crcs intact first?

T1;1;1;2019-04-04 19:39:22.000;85;79;01592846;0x6e4401064628590105070dcc7ac90060856604f715a3273a670e3cce0b9881b86739771b9375de75fccbdcc12e01f288a9efea4554dd3fed1f86f003ae3bc0b9e26dbc5fdaf0cc5ade6cf867b410aeb5e4799587c5d8806c5e184e07681edc64e1a2bf878d5c84f15f87ce2fdf8f3ff88d949610e639c5979ff807bae84e86;0x6e4401064628590105077ac90060856604f715a3273a670e3cce81b86739771b9375de75fccbdcc12e01a9efea4554dd3fed1f86f003ae3bc0b9bc5fdaf0cc5ade6cf867b410aeb5e479c5d8806c5e184e07681edc64e1a2bf8784f15f87ce2fdf8f3ff88d949610e6399ff807bae8<0A>

[xaelsouth]

Ok, i have the recording - will check this next weekend.

To the large output in your last message: yes, someone has concatenated both printf() in t1_c1_packet_decoder.h . First printf (wrapped by #if 0) would print full datagram with CRC whilst second printf (wrapped by #if 1) prints "cooked" datagram without CRC bytes.

[weetmuts]

Hi @xaelsouth ! Did you have any luck in decoding the C1 telegrams?

[xaelsouth]

Re: [xaelsouth/rtl-wmbus] rtl-sdr.com (#4) Hello Fredrik, no, i'm sorry. Don't had have time for that. :( On vacation, eventually. :) Sunday, July 7, 2019, 9:42:03 PM, you wrote: Hi @xaelsouth ! Did you have any luck in decoding the C1 telegrams? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

…

-- Best regards,  Xael                            mailto:xael.south@yandex.com