Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Orange Pi zero #2

Closed
pawart opened this issue Jan 21, 2018 · 6 comments
Closed

Orange Pi zero #2

pawart opened this issue Jan 21, 2018 · 6 comments

Comments

@pawart
Copy link

pawart commented Jan 21, 2018

Hi!

Unfortunatly all options to make the rtl-wmbus failed on a Orange Pi zero.
Could you pls provide guidance on what I could use?

Will continue with the raspberry pi and the windows version.

thx.

-x-

me@orangepizero:~/ rtl-wmbus$ make debug # gcc -msse4.2 -DDEBUG -O0 -g3 -ggdb -p -pg -Iinclude -std=gnu99 -Wall -W -Waggregate-return -Wbad-function-cast -Wcast-align -Wcast-qual -Wchar-subscripts -Wcomment -Wfloat-equal -Winline -Wmain -Wmissing-noreturn -Wmissing-prototypes -Wparentheses -Wpointer-arith -Wredundant-decls -Wreturn-type -Wshadow -Wsign-compare -Wstrict-prototypes -Wswitch -Wunreachable-code -Wunused -Wuninitialized -o "build/rtl_wmbus" rtl_wmbus.c -lm gcc: error: unrecognized command line option ‘-msse4.2’ Makefile:22: recipe for target 'debug' failed make: *** [debug] Error 1 domo@orangepizero78:~/rtl-wmbus$

me@orangepizero:~/ rtl-wmbus$ make pi1 # gcc -DNDEBUG -O3 -march=armv6 -mtune=arm1176jzf-s -mfloat-abi=hard -mfpu=vfp -ff ast-math -Iinclude -std=gnu99 -Wall -W -Waggregate-return -Wbad-function-cast -W cast-align -Wcast-qual -Wchar-subscripts -Wcomment -Wfloat-equal -Winline -Wmain -Wmissing-noreturn -Wmissing-prototypes -Wparentheses -Wpointer-arith -Wredunda nt-decls -Wreturn-type -Wshadow -Wsign-compare -Wstrict-prototypes -Wswitch -Wun reachable-code -Wunused -Wuninitialized -o "build/rtl_wmbus" rtl_wmbus.c -lm In file included from /usr/include/endian.h:60:0, from /usr/include/arm-linux-gnueabihf/bits/waitstatus.h:64, from /usr/include/stdlib.h:42, from rtl_wmbus.c:28: /usr/include/arm-linux-gnueabihf/bits/byteswap.h: In function ‘__bswap_32’: /usr/include/arm-linux-gnueabihf/bits/byteswap.h:45:1: sorry, unimplemented: Thu mb-1 hard-float VFP ABI { ^ In file included from rtl_wmbus.c:37:0: atan2.h: In function ‘atan2_approximation2’: atan2.h:48:11: warning: comparing floating point with == or != is unsafe [-Wfloa t-equal] if (x == 0.0f) ^ atan2.h:51:15: warning: comparing floating point with == or != is unsafe [-Wfloa t-equal] if (y == 0.0f) return 0.0f; ^ In file included from rtl_wmbus.c:38:0: net_support.h: In function ‘get_net’: net_support.h:17:12: warning: missing initializer for field ‘sin_addr’ of ‘struc t sockaddr_in’ [-Wmissing-field-initializers] struct sockaddr_in address = {.sin_family = AF_INET, .sin_port = htons(port ^ In file included from /usr/include/arpa/inet.h:22:0, from net_support.h:7, from rtl_wmbus.c:38: /usr/include/netinet/in.h:243:20: note: ‘sin_addr’ declared here struct in_addr sin_addr; /* Internet address. */ ^ rtl_wmbus.c: At top level: rtl_wmbus.c:43:23: fatal error: immintrin.h: No such file or directory compilation terminated. Makefile:26: recipe for target 'pi1' failed make: *** [pi1] Error 1

@xaelsouth
Copy link
Owner

Please update your git copy of the project. I've just removed the "-sse4.2" compiler option from Makefile. This should be sufficient, but i have no orange pi zero to test it out. Write me if still in troubles.

@pawart
Copy link
Author

pawart commented Jan 23, 2018

Hi
thx for the reply - I have moved forward with the pi - there I had to remove the android section - then it compiled & retunrned the "2" value fro sample2.bin. Great!

Did you actually try it with such devices: mgroup aka elf with wirless mbus
http://www.apator.com/en/offer/water-and-heat-metering/heat-meters/elf-compact-heat-meter

I would like to integrate it with domoticz (https://domoticz.com/) which natively supports the rtl-sdr module.

  • which workes fine with the parameter:
    -f 433.92e6 -f 868.24e6 -H 60
    so I exchanged it with:
    -f 868.9M -s 1600000 - 2>/dev/null | build/rtl_wmbus
    which again returnd heaps of junk.

ok let me know - any help apreciated!

I keep getting gribbish. should I change the antenna,,,? do fine tuning ...? How? Thx!

@xaelsouth
Copy link
Owner

As stated in http://www.apator.com/uploads/files/Produkty/Cieplomierze/elf/i-en-009-2017-elf-13-01.pdf the operating frequency of your heatmeter is 868.95 Mhz - just like devices which i have already tested (see sample2.bin). If in doubts concerning "-f 868.9M" setting, i would recommend to check the radio signal if it is there near to this frequency, for example by using gqrx. You have to expect the heatmeter signal as two "splashes" at the distance of about 50kHz each near to 868.95Mhz. Set the cursor just in between of these two splashes and notice the frequency - you have to use it in the command line.

@xaelsouth
Copy link
Owner

I did not use the standard DVB-T antenna which is typically optimized for 400-600Mhz. I have a small SMA 50 ohms antenna which is connected with an "MCX Jack to SMA RF Cable Adapter" to the DVB-T dongle. Antenna matching is obviously worse ;-), but absolutely sufficent for you purpose.

@xaelsouth
Copy link
Owner

I have neither experience with "elf with wirless mbus" nor i have used https://domoticz.com . BTW, thanks for sharing the link.

@pawart
Copy link
Author

pawart commented Jan 24, 2018

ok, so these are my findings so far:

  • domoticz still spits out gribbish :( - will adapt the frequency to 868.9(5) & check with gqrx as suggested. thx.
  • in parallel I have installed fhme which is definitly more advanced on the wmbus area inc. aes decription etc. and integration for metering.
    but (almost!) noone seems to have ever integrated a dvd stick or rflink. How is that even possible?! & What a pitty!! Did you get it to run with fhem?

So I have one system that can display gribbish and another that could decode it but I am missing a pipe between them.... maybe this is even possible but I would have to investigate further in the endless manuals of fhem. what is your suggestion ...?

There are two more things that could help now:

  1. Try to pipe the rtl-sdr output into fsme as some kind of "DVB-"CUL" (how ...?) my plan A.
  2. fhem + tefrec + mqtt + mosquito + dvb + rtl-sdr etc...
    The only one who really sems to have botherd accessing a dvb stick - und does so with a wrapper called tfrec.
    https://github.com/git-developer/fhem-examples/wiki/Temperatur-Feuchte-Sender-mit-tfrec-und-MQTT
    => I alreday have a mqtt broker in my net & that would be overkill I guess for now - so plan B
  3. Skim through the other sdr-uniqhorn in the fhme ecosphere "SDR tool for receiving wireless sensor data (TFA IT+ KlimaLogg Pro)" for clues that might help interate it but there is a linbe that tells me: No:
    "Received values must be externaly fed to a database, FHEM, etc!"
    https://github.com/baycom/tfrec so: Plan C.

Honestly: would a chat with you. In exchange for a working wbus I would show you all the cool domoticz stuff i did so far :) so let me know what you think about it. u got my email. All for now, BrP

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants