ESP D1 Mini

[Johnep101]

Hi Invandy, John again. Sorry to bother you but Ive moved over to a D1 Mini esp32 module, code was running great on my ESP Node MCU dev 12 module. I now have some of the ESP32 modules and would like to run it on them. I can see code coming in if I use the "Oscilloscope" mode and occasionally I do get valid data. I wonder if it is anything to do with the faster clock speed of the ESP module? I am using this start up code:-
........ Oregon_NR oregon(27, 27, // output receiver 27 (GPIO27) 255, true, // The LED on D2 is pulled up to + power (true). If the LED is not needed, then the pin number- 255 50, true); // Buffer for receiving a parcel from 50 nibls, package assembly for v2 is included ........
with data connected to GPIO27. this is a typical data output = BEFORE OI OI OI OI OI OI OI OI OI OI OI OI OI OI OI OI OI OI OI OI OI OI OO II OO II OI OO IO IO II OO IO II OO IO IO II OO IO II OO IO IO IO IO II OO II OI OO IO IO II OO IO IO IO II OO II OI OO IO IO IO IO IO II OI OO IO IO IO IO IO IO IO IO IO IO IO IO IO IO IO IO IO IO IO IO IO IO IO IO IO II OO IO IO II II II II II II II II II II II II II II II II II II II II II II II II II II II II II II II II II II II II II II II II OO AFTER OI OI OI OI OI OI OI OI OI OI OI OI OI OI OI OI OI OI OI OI OI OI OO II OO II OI OO IO IO II OO IO II OO IO IO II OO IO II OO IO IO IO IO II OO II OI OO IO IO II OO IO IO IO II OO II OI OO IO IO IO IO IO II OI OO IO IO IO IO IO IO IO IO IO IO IO IO IO IO IO IO IO IO IO IO IO IO IO IO IO II OO IO IO II OO II OO II OO II OO II OO II OO II OO II OO II OO II OO II OO II OO II OO II OO II OO II OO II OO II OO II OO II OI OO type 6532 ( which I think is the WGR800 wind speed).

any help or pointers would be gratefully received.

many thanks

John

[invandy]

Hi, John. With such quality oscilloscope data you have to get a correct packet. So I have no any idea. If you show the complete dump maybe it might clarify something.

[Johnep101]

Hello, and thank you for your reply. I have received a few packets of valid data, so I reckon it might be down to some interference, possibly from the ESP WiFi section. I hope to run some tests tomorrow where I will turn off the WiFi and see if that helps. I will let you know. Thanks again. John.

[Johnep101]

Hello again, as promised an update of today's activity. I read your big article on the decoding process and found it very helpful, a great piece of work. As of yesterday I occasionally got a valid data packet from the anemometer but very rarely from the rain gauge. Based on that I figured maybe my receiver needed more gain, so I found this article https://www.instructables.com/433-MHz-Coil-loaded-antenna/ on improving the sensitivity by using antennas. I built two, connected one to the ground pin and one to the antenna pin and bingo, absolutely nothing!!! After some Head scratching I then downloaded a "raw data" sniffer and although I live in a low population density area my screen was full of data coming from all sorts of sensors. So it seems that the anemometer data gets through because it sends data more often. I took off the antenna, wired the rain gauge directly into a spare interrupt pin and I will live with the occasional update from the anemometer. I use the data to calculate the evapotranspiration rate for my irrigation system (again using NodeMCU and Blynk) so I can happily work with this system. Thanks again for a great piece of work and your help. John.

[invandy]

As I know ESP8266 microcontroller is quitely noisy in wide frequency range. I suppose that ESP32 has the similar problem. So you may try to improve receiving by moving receiver away from esp as far as possible and organizing for it a pure independent supply. As for antenna, it seems to me that straight piece of wire have to receive better than coiled one. As I remeber such antenna has a larger effective area (absorbtion area), But I'm not sure :)

[Johnep101]

Hi again, yes I did move the receiver about 15cm away with no effect and I also provided an extra stable supply. The antenna is called a "loaded dipole" and gives very good results for a shorter length. Doing more investigation it does seem like there is just too much traffic in the band, I'm getting More than 40 valid messages per second plus more that are corrupt and these just clash with the random weather station data. But many thanks for your help, I can get what I need for now.

[donwade]

You may wish to buy a cheap sdr and use gqrx to scan the ism 433 band to see if it’s noisy or not. And you’d be able to see if the esp32 generates ism noise into the air and back into 433 antenna. The esp wifi section is nicely sealed in a tin can (on my version) so I’m guessing it can’t leak. Now the wifi runs at 6x higher frequency than 433 devices do so it can’t generate harmonics downward. However I guess if the esp antenna is Uber NEAR the 433 antenna it might swamp the front end. I currently run a rfm96 in ook mode with an esp32 with wifi off and it sees Oregon packets streaming by.

On Feb 26, 2021, at 4:02 AM, JohnP notifications@github.com wrote:

 Hi again, yes I did move the receiver about 15cm away with no effect and I also provided an extra stable supply. The antenna is called a "loaded dipole" and gives very good results for a shorter length. Doing more investigation it does seem like there is just too much traffic in the band, I'm getting More than 40 valid messages per second plus more that are corrupt and these just clash with the random weather station data. But many thanks for your help, I can get what I need for now.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[donwade]

Also the 433 ism band is about 1.7 MHz wide. The cheap receivers have to have the same receive width (as the desired transmitter can be anywhere in that band). Unfortunately by having wide input, other people chatting on the band are mushed up with your signal. Cheap receivers have no selectivity to say “focus only on my transmitter at 433.12345”. For selectivity you’ll have to move to gnuradio (ugh a laptop) or to the rfm69 to dial in an exact frequency. Moving to a rfm69 for Oregon won’t work “out of the box” with anyone’s GitHub implementation of rfm69 due to some weird things Oregon does.

On Feb 26, 2021, at 11:17 AM, Don Wade don_wade@rogers.com wrote:

 You may wish to buy a cheap sdr and use gqrx to scan the ism 433 band to see if it’s noisy or not. And you’d be able to see if the esp32 generates ism noise into the air and back into 433 antenna. The esp wifi section is nicely sealed in a tin can (on my version) so I’m guessing it can’t leak. Now the wifi runs at 6x higher frequency than 433 devices do so it can’t generate harmonics downward. However I guess if the esp antenna is Uber NEAR the 433 antenna it might swamp the front end. I currently run a rfm96 in ook mode with an esp32 with wifi off and it sees Oregon packets streaming by.

On Feb 26, 2021, at 4:02 AM, JohnP notifications@github.com wrote:

 Hi again, yes I did move the receiver about 15cm away with no effect and I also provided an extra stable supply. The antenna is called a "loaded dipole" and gives very good results for a shorter length. Doing more investigation it does seem like there is just too much traffic in the band, I'm getting More than 40 valid messages per second plus more that are corrupt and these just clash with the random weather station data. But many thanks for your help, I can get what I need for now.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[Johnep101]

Hi both, Again thanks for your comments, as my esp is going to be relatively close to the anemometer my latest thoughts are to get into the Oregon electronics and intercept the signal going to the transmitter and route this via wire to the esp input pin currently connected to the receiver and then let Invandys great code interpret the signal, job for tomorrow as we have more rain forecast (who needs irrigation🤣🤣) I’ll keep you posted! Cheers.

Best regards

John.

On 26 Feb 2021, at 16:35, donwade notifications@github.com wrote:

 Also the 433 ism band is about 1.7 MHz wide. The cheap receivers have to have the same receive width (as the desired transmitter can be anywhere in that band). Unfortunately by having wide input, other people chatting on the band are mushed up with your signal. Cheap receivers have no selectivity to say “focus only on my transmitter at 433.12345”. For selectivity you’ll have to move to gnuradio (ugh a laptop) or to the rfm69 to dial in an exact frequency. Moving to a rfm69 for Oregon won’t work “out of the box” with anyone’s GitHub implementation of rfm69 due to some weird things Oregon does.

On Feb 26, 2021, at 11:17 AM, Don Wade don_wade@rogers.com wrote:

 You may wish to buy a cheap sdr and use gqrx to scan the ism 433 band to see if it’s noisy or not. And you’d be able to see if the esp32 generates ism noise into the air and back into 433 antenna. The esp wifi section is nicely sealed in a tin can (on my version) so I’m guessing it can’t leak. Now the wifi runs at 6x higher frequency than 433 devices do so it can’t generate harmonics downward. However I guess if the esp antenna is Uber NEAR the 433 antenna it might swamp the front end. I currently run a rfm96 in ook mode with an esp32 with wifi off and it sees Oregon packets streaming by.

On Feb 26, 2021, at 4:02 AM, JohnP notifications@github.com wrote:

 Hi again, yes I did move the receiver about 15cm away with no effect and I also provided an extra stable supply. The antenna is called a "loaded dipole" and gives very good results for a shorter length. Doing more investigation it does seem like there is just too much traffic in the band, I'm getting More than 40 valid messages per second plus more that are corrupt and these just clash with the random weather station data. But many thanks for your help, I can get what I need for now.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[Johnep101]

Hi just a final comment on this topic. The Oregon scientific is not made for disassembly! So I couldn't get access to the raw data line. I made a small box to put the receiver in and fixed this to the side of the anemometer near the transmitter antenna. All works fine and I get regular updates from the anemometer which I use in my Blynk weather app. Thank again!

[kroon040]

Hi John,

I Also want to tun it on an esp32 . Do you have it running with MQTT?

regards Richard

[donwade]

I got a Oregon version working with a TTGO esp32 (the version with integrated oled display and sx1726 rf 433 hardware). Design built from ground zero. Uses wifi to get network time and the SD card for data longing. The only part of invandys work I used was the CRC/checksum routines. It will appear as a fork under the rfm Radiolib tree. Unfortunately I’m recovering from surgery and it won’t appear til later this week 😬😑

On Dec 14, 2021, at 4:56 PM, kroon040 @.***> wrote:

 Hi John,

I Also want to tun it on an esp32 . Do you have it running with MQTT?

regards Richard

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

[Johnep101]

Good morning, No experience with MQTT, sorry. I run all my IoT stuff through Blynk, mostly on the old system but now migrating to the new Blynk platform. If you look on the Blynk furors Peter Knight has done a lot of work with MQTT.

Good luck with the recovery Don👍

below is a screen shot of my weather station, I use a BME280 for temperature, Humidity and pressure then tap into the Oregon system via 433 MHz for wind speed, direction and rainfall. I use a photo diode to measure solar flux, then wrap the whole thing up with a modified Pennman formula to send “required water” to my Blynk irrigation app.

Best regards

John

On 14 Dec 2021, at 22:22, Don Wade @.***> wrote:

 I got a Oregon version working with a TTGO esp32 (the version with integrated oled display and sx1726 rf 433 hardware). Design built from ground zero. Uses wifi to get network time and the SD card for data longing. The only part of invandys work I used was the CRC/checksum routines. It will appear as a fork under the rfm Radiolib tree. Unfortunately I’m recovering from surgery and it won’t appear til later this week 😬😑

On Dec 14, 2021, at 4:56 PM, kroon040 @.***> wrote:

 Hi John,

I Also want to tun it on an esp32 . Do you have it running with MQTT?

regards Richard

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[donwade]

I finally got my code up and running. It uses a esp32 with a ttgo 433/oled radio board It doesn't use the pure hw OOK functionality the radio provides (OS is weird OOK) but I configure the hardware for direct rf bit read with h/w squelch etc. I originally did use a dumb 433 device but I moved to the ttgo 433 board for improved sensitivity and noise rejection. I did steal (sorry re-used) Invandy's crc/csum routines (wow, great work there. I'd never figure that out)

1) logs to sd card (optional) 2) connects to wifi for ntp time so logs are nice. (optional) 3) limits b/w to 250Khz so I don't get creamed by our neighborhood ham radio operator :) 4) uses packed structures because people say you shouldn't use it, but lordie, no shift/mask/shift compare routines in my code. Ordered packing for esp32, I don't care about other architectures. 5) each OS sensor sits in its own file. I only did 4 of many. 6) I wanted to see if a ino Arduino project can use ISRs/tasks/semaphores/message queues etc, so I got away from "loop()" 7) Putty log included.

https://github.com/donwade/RadioLib

[Johnep101]

Wow nice job👍 Well done