Closed vistalba closed 1 year ago
That's a simple typo, the default_envs line should look like this
default_envs = lilygo-rtl_433
Thanks. That worked. But strange that this lilygo-rtl_433
is not in the platformio.ini file at all.
I was able to change the frequency now but I do not see any RF singals recieved. :(
But strange that this
lilygo-rtl_433
is not in the platformio.ini file at all.
It will be included ;) thanks for pointing this out.
I was able to change the frequency now but I do not see any RF singals recieved. :(
How did you change the frequency? in your above environment I can see that you defined
'-DCC1101_FREQUENCY=868.32'
but, as the name implies, this is only applicable to the CC1101 transceiver, which is not being used by the LilyGo board, but the above defined on-board SX127x
radio. So the CC1101 frequency setting will not have any effect.
While I am not really sure if and how well the frequency change on a 433Mhz board will be, the supposed command to change it should be
https://docs.openmqttgateway.com/use/rf.html#rtl-433-device-decoders
Let us know how you get on.
Thanks for your feedback. I thought the same about the '-DCC1101_FREQUENCY=868.32'
but it lookw like it works. Or at least I see the mhz set in the SYStoMQTT
topic.
Example after boot:
{
"uptime": 4,
"version": "version_tag",
"freemem": 168500,
"mqttport": "1883",
"mqttsecure": false,
"tempc": 54.44444,
"freestack": 4632,
"rssi": -56,
"SSID": "MySSID",
"BSSID": "44:D9:E7:XX:XX:XX",
"ip": "10.100.X.XX",
"mac": "C8:C9:A3:XX:XX:XX",
"actRec": 3,
"mhz": 868.32,
"RTLRssiThresh": -82,
"RTLRssi": -115,
"RTLAVGRssi": 0,
"RTLCnt": 0,
"RTLOOKThresh": 90,
"modules": [
"rtl_433"
]
}
I have an RTL-SDR Dongle on a Pi which ha 868.319MHz configured and is working fine with the Fine Offset Electronics WH1080 decoder. So, why it does not work on OpenMQTTGateway? I set it to 868.32MHz as it does only support 2 decimals.
Additinally I've tried with sending the { "mhz":868.32 }
which does also not help at all.
When sending a { "status":1 }
I do get the debug infos like this:
{
"model": "status",
"protocol": "debug",
"debug": 0,
"duration": 250094149,
"Gap length": 4749667,
"rssi": 0,
"train": 0,
"messageCount": 0,
"totalSignals": 0,
"ignoredSignals": 0,
"unparsedSignals": 0,
"_enabledReceiver": 1,
"receiveMode": 0,
"currentRssi": -116,
"rssiThreshold": -106,
"pulses": -1,
"StackHighWaterMark": 4632,
"freeMem": 173584
}
So for me it looks like it does not get any messages at all. So it is not a decoder issue at this time. It does not get any RF signals.
I do use this board. May this is an issue and not compatbile with the one with OLED display?
I have an RTL-SDR Dongle on a Pi which ha 868.319MHz configured and is working fine with the Fine Offset Electronics WH1080 decoder
There are two versions of the WH1080, one with OOK_PULSE_PWM
modulation, and one with FSK_PULSE_PCM
modulation. Only the OOK_PULSE_PWM
is decodable by rtl_433_ESP, any FSK modulation isn't (yet) and might not easily be implemented at all. So this might be the case with your Weather Station, or the frequency setting needs some additional/different adjustments I am not aware of.
https://github.com/NorthernMan54/rtl_433_ESP/issues/5
I'm in the same boat with my FSK weather station.
Do you know how I can find out if my weather station uses OOK_PULSE_PWM
or FSK_PULSE_PCM
?
In rtl433 on the pi it looks like this: Can't see any indicator which shows me the modulation information :(
Can you set RTL_433 to a more verbose setting to show additional data? The actual .name property I references above should differentiate between
.name = "Fine Offset Electronics WH1080/WH3080 Weather Station",
and
.name = "Fine Offset Electronics WH1080/WH3080 Weather Station (FSK)",
Also the sample screenshot on the RTL_433 page shows Modulation and Frequency in the output, so there should be a setting to have these included.
It could also be the shorter reception range of a LilyGo board, compared to a full blown RTL-SDR stick connected to a Pi.
Just had to find out how to get this information... it's OOK in my case. The -A
setting did it.
Reading samples in async mode...
Tuned to 868.319MHz.
Detected OOK package 2023-02-22 17:31:33
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time : 2023-02-22 17:31:33
model : Fineoffset-WHx080 Msg type : 2 UV Sensor ID: 5 Sensor Status: OK UV Index : 0 Lux : 930.0 Watts/m : 1.36
Integrity : CRC
Analyzing pulses...
Total count: 64, width: 127.79 ms (31948 S)
Pulse width distribution:
[ 0] count: 1, width: 328 us [328;328] ( 82 S)
[ 1] count: 27, width: 496 us [492;504] ( 124 S)
[ 2] count: 36, width: 1472 us [1468;1480] ( 368 S)
Gap width distribution:
[ 0] count: 63, width: 964 us [960;972] ( 241 S)
Pulse period distribution:
[ 0] count: 27, width: 1456 us [1292;1472] ( 364 S)
[ 1] count: 36, width: 2440 us [2432;2452] ( 610 S)
Pulse timing distribution:
[ 0] count: 1, width: 328 us [328;328] ( 82 S)
[ 1] count: 27, width: 496 us [492;504] ( 124 S)
[ 2] count: 36, width: 1472 us [1468;1480] ( 368 S)
[ 3] count: 63, width: 964 us [960;972] ( 241 S)
[ 4] count: 1, width: 14804 us [14804;14804] (3701 S)
Level estimates [high, low]: 15944, 3
RSSI: -0.1 dB SNR: 37.3 dB Noise: -37.4 dB
Frequency offsets [F1, F2]: 18396, 0 (+70.2 kHz, +0.0 kHz)
Guessing modulation: Pulse Width Modulation with sync/delimiter
view at https://triq.org/pdv/#AAB105014801F005C003C439D48393939393939393A3939393A3A3A3A3A393A393A3A3A3A3A393A393A393A393A3A3A3A3A3A3A3A3A3A393A3A393A3A3A393A393A393A3A39393A3939393A39455
Attempting demodulation... short_width: 496, long_width: 1472, reset_limit: 976, sync_width: 328
Use a flex decoder with -X 'n=name,m=OOK_PWM,s=496,l=1472,r=976,g=0,t=0,y=328'
pulse_slicer_pwm(): Analyzer Device
bitbuffer:: Number of rows: 1
[00] {63} fe e0 a0 aa 00 48 a9 ba
it's OOK in my case
So I would assume it should be decoded in your case.
Is your LilyGo a dedicated 868Mhz version board, as indicated in the pinout image above?
Any chance of getting the LilyGo closer to the weather station, to see if the reception distance might be the issue?
it's OOK in my case
So I would assume it should be decoded in your case.
Is your LilyGo a dedicated 868Mhz version board, as indicated in the pinout image above?
Any chance of getting the LilyGo closer to the weather station, to see if the reception distance might be the issue?
Yes, it is exactly that version. Package is labeled as "LilaGo TTGO LoRa V1.0 ESP32 SX1276 EU868". I tried already to get closer. At the moment it is around 5 meters away in direct line of sight without anything in between. So I guess this should work. Maybe a frequency shift? Any Idea how to find that out? In RTL-SDR on rPi I use 868.319MHz as frequency. But may one of the device has a offset. But I don't know how to test that with ESP32.
I'll have to leave that to @NorthernMan54 as I'm out of my league here, but hope you get your OOK_PWM weather station integrated eventually.
@DigiH Thanks you your help anyway. Absolutly welcome!
@vistalba could you try this branch, please https://github.com/1technophile/OpenMQTTGateway/tree/ttgo-lora32-v1 With this environment:
[env:ttgo-lora32-v1-rtl]
platform = ${com.esp32_platform}
board = ttgo-lora32-v1
board_build.partitions = min_spiffs.csv
lib_deps =
${com-esp.lib_deps}
${libraries.wifimanager32}
${libraries.ssd1306}
${libraries.rtl_433_ESP}
build_flags =
${com-esp.build_flags}
'-DvalueAsATopic=true' ; MQTT topic includes model and device
'-DGateway_Name="OpenMQTTGateway_ttgo_v1"'
; *** OpenMQTTGateway Modules ***
'-DZgatewayRTL_433="rtl_433"'
'-DZradioSX127x="SX127x"'
'-DRF_SX1276="SX1276"'
'-DRF_MODULE_RECEIVER_GPIO=33'
'-DRF_MODULE_CS=LORA_CS'
'-DRF_MODULE_DIO0=LORA_IRQ'
'-DCC1101_FREQUENCY=868.3'
'-DRF_MODULE_DIO2=35' ; To avoid build error with RTL_433_ESP
'-DRF_MODULE_RST=LORA_RST'
'-DRF_MODULE_DIO1=33' ;PIN_RECEIVER_GPIO
'-DZdisplaySSD1306="LilyGo_SSD1306"'
'-DDISPLAY_IDLE_LOGO=true'
'-DLOG_LEVEL=LOG_LEVEL_TRACE'
custom_hardware= ESP32 TTGO LORA V1
I have the board at 868/915mhz but no device to test with
@1technophile I compiled the suggested branch. The board comes up in WiFi and MQTT broker directly with 868.3MHz. Still no decoded messages from my Weather Station. What I see, there are some recieved signals but they are ignored:
{
"model": "status",
"protocol": "debug",
"debug": 0,
"duration": 962961,
"Gap length": 546641873,
"rssi": -56,
"train": 0,
"messageCount": 0,
"totalSignals": 9,
"ignoredSignals": 9,
"unparsedSignals": 0,
"_enabledReceiver": 1,
"receiveMode": 0,
"currentRssi": -107,
"rssiThreshold": -97,
"pulses": -1,
"StackHighWaterMark": 4808,
"freeMem": 162508
}
@NorthernMan54 what would you suggest to debug this ?
The ignored signals are essentially noise or static that was picked up by the receiver, then ignored.
If you recompile with the DEMOD_DEBUG and PUBLISH_UNPARSED options, it should show more details of the signals received on the serial output.
But with that said, I’m wondering if the transceiver settings need further tuning for 868 MHz. To look at this, I would need to create a fake 868 MHz sensor to transmit test data,( I don’t have a 868 MHz device ) then setup a board to test the receiver.
Without recreating your setup, I’m stumped. It appears that your ESP is connecting to the SX127x transceiver okay ( RSSI levels ) so am thinking it’s the chipset tuning.
I’m out of the country for the next few weeks, so will be a while before I can get to this.
@NorthernMan54 Just tried what you suggested... seeing now a lot of such log lines in the debug terminal on VSCode:
rtl_433_ESP(6): Ignored Signal length: 10000, Time since last bit length: 100460, Gap length: 9665831, Signal RSSI: -91, Current RSSI: -107, pulses: -1, noise count: 0
rtl_433_ESP(6): Ignored Signal length: 5000, Time since last bit length: 100576, Gap length: 3025831, Signal RSSI: -86, Current RSSI: -105, pulses: -1, noise count: 0
rtl_433_ESP(6): Ignored Signal length: 6000, Time since last bit length: 100399, Gap length: 928818, Signal RSSI: -92, Current RSSI: -107, pulses: -1, noise count: 0
rtl_433_ESP(6): Ignored Signal length: 6000, Time since last bit length: 100244, Gap length: 63082, Signal RSSI: -94, Current RSSI: -107, pulses: -1, noise count: 0
rtl_433_ESP(6): Ignored Signal length: 118324, Time since last bit length: 100365, Gap length: 729053, Signal RSSI: -90, Current RSSI: -107, pulses: -1, noise count: 0
rtl_433_ESP(6): Ignored Signal length: 4054, Time since last bit length: 100281, Gap length: 172947, Signal RSSI: -90, Current RSSI: -107, pulses: -1, noise count: 0
rtl_433_ESP(6): Ignored Signal length: 382001, Time since last bit length: 101460, Gap length: 9133173, Signal RSSI: -96, Current RSSI: -107, pulses: -1, noise count: 0
rtl_433_ESP(6): Ignored Signal length: 102000, Time since last bit length: 100409, Gap length: 5236744, Signal RSSI: -95, Current RSSI: -108, pulses: -1, noise count: 0
rtl_433_ESP(7): Average RSSI Signal -106 dbm, adjusted RSSI Threshold -97, samples 50000
rtl_433_ESP(6): Ignored Signal length: 394000, Time since last bit length: 100461, Gap length: 14557526, Signal RSSI: -95, Current RSSI: -108, pulses: -1, noise count: 0
rtl_433_ESP(6): Ignored Signal length: 5000, Time since last bit length: 100455, Gap length: 14921656, Signal RSSI: -91, Current RSSI: -107, pulses: -1, noise count: 0
rtl_433_ESP(6): Ignored Signal length: 172052, Time since last bit length: 100465, Gap length: 11982190, Signal RSSI: -95, Current RSSI: -107, pulses: -1, noise count: 0
rtl_433_ESP(6): Ignored Signal length: 119000, Time since last bit length: 100416, Gap length: 2621600, Signal RSSI: -91, Current RSSI: -107, pulses: -1, noise count: 0
rtl_433_ESP(6): Ignored Signal length: 4000, Time since last bit length: 100295, Gap length: 171800, Signal RSSI: -90, Current RSSI: -107, pulses: -1, noise count: 0
rtl_433_ESP(7): Average RSSI Signal -106 dbm, adjusted RSSI Threshold -97, samples 50000
rtl_433_ESP(6): Ignored Signal length: 5000, Time since last bit length: 100431, Gap length: 14967215, Signal RSSI: -93, Current RSSI: -107, pulses: -1, noise count: 0
rtl_433_ESP(6): Ignored Signal length: 4000, Time since last bit length: 100459, Gap length: 14951863, Signal RSSI: -92, Current RSSI: -107, pulses: -1, noise count: 0
rtl_433_ESP(6): Ignored Signal length: 165000, Time since last bit length: 100464, Gap length: 14583832, Signal RSSI: -96, Current RSSI: -106, pulses: -1, noise count: 0
rtl_433_ESP(6): Ignored Signal length: 4000, Time since last bit length: 100259, Gap length: 71652, Signal RSSI: -93, Current RSSI: -107, pulses: -1, noise count: 0
@vistalba the ignored signal length message, is generated when the receiver sees a potential signal, but no bits are captured.
Am going to need to try and recreate this in my test lab
@NorthernMan54 let me know if I can help with everything further.
Just cleaning up space in my development setup, and should get to this in a day or 2. Currently update rtl_433_ESP with the latest rtl_433 decoders.
This issue is stale because it has been open for 30 days with no activity.
This issue was closed because it has been inactive for 7 days since being marked as stale.
May I'm to new to this. But I can't find which default_envs to build which uses env:lilygo-rtl_433.
The reason why I want to build it by myself is just because I must change the frequency: '-DCC1101_FREQUENCY=868.32'
So I downloaded VSC, PlatformIO. Created a "custom_env.ini" file which looke like this:
But this just results in the error:
Any advice?