Go Down

Topic: Questions receiving Oregon v1 data (Read 8152 times) previous topic - next topic

robwlakes

Quote
I had my sketch aligned to the edge of the sync, but, after the sync part, through the message, it always moves in steps of one quarter of wave. That means that if the delays I'm using are not accurate enough (and they probably aren't), I could be out of sync after a few cycles. As the message is quite short (32 bits), the code worked and I got away with it, but if the conditions change then it could break.

I've changed my code to solve this. First, I don't look for the preamble at all, I just go for the sync. In fact, the code works if you only look for the second part (the high zone) of the sync, but I detect too the first low part because there were too many fake positives (although the message for them is invalid). Then align to the falling edge of the second zone, wait for what I think is the delay of the third pulse (5100 microseconds) and start a loop to read bits: wait one quarter, read possible value, wait for edge (this realigns the timings), wait one quarter, confirm the value has changed and then wait for another quarter to be at the beginning of the next bit. This should be much more robust than before.
Have you improved the reliability?

Cheers, Rob
Learning Flute and C++, heading for a meltdown.

kokopa

Have you improved the reliability?
The message is quite sort and in the tests I did before the change the reliability was good. However, I've made much more tests after the change (realigning the timing each bit) and the reliability is extremely good. I didn't lose a single message after many hours.

If you remove the first part of the code (the one that says it's optional), the reliability is worse, because sometimes it confuses the end of the message with a sync part, so you may lose the second repeated message. It's still not bad (you get one message and sometimes even both of them) but since you don't need it, I wouldn't remove it.

robwlakes

Quote
I didn't lose a single message after many hours.
Well Kokopa that sounds really excellent!!!  ;) That's put a smile on my dial!!

I think you are right about the header's purpose and what you are saying about making sure it does not get confused by the data as header etc is good thinking.  It does not require much code and the Arduino is not doing much apart from that anyway, so why not go for the more complete solution.

So how does this all fit in with the overall objective of the project? Are you now close to finishing it up?

Cheers, Rob
Learning Flute and C++, heading for a meltdown.

kokopa

Thank! I know this small project is quite easy (specially thanks to the work and help from people like you!), but since I'm starting with Arduino, sensors and so on, I'm quite proud and I've learned a lot of things. About the project, one of my problems is the receiving range. I can't put a good antenna on the receiver (I know about the optimal length and now I've ordered one to see if I get better results).

In the meantime, I'm trying to do a TinyTx (following the tutorials from Nathan Chantrell). I have a raspberry and my final project would be to make it log data from several sensors around my home. Decoding the Oregon through the Raspberry may be cpu consuming, but with the TinyTx there are many solutions already available (like the RFM12Pi).

robwlakes

Those other projects featuring the Tiny are very interesting, however they do point to one thing, in my mind at least, is that is best to have a dedicated Arduino style CPU doing the receiving of the 433MHz.  I have yet to see a good, simple project that clearly shows how to directly intercept 433MHz with a RPi.

Hence I think using a Tiny as a pre-processor so to speak is probably a good idea.  I have found problems with signal strength as well.  Most times though, the "Bad reception" has been because of flaky code, rather than RF problems.  However to allay my suspicions I have experimented with what would be the "best" antenna and found this solution to be particularly effective.  This is a photo of the setup before I went the next step.  I have added to it graphically to explain the setup.

The first experiment was to have a length of TV coaxial cable with the shield stripped back for 17cm at the other end from the Tx or Rx (Yellow line).  This was fairly good, but I found when I added a matching length of hookup wire to (where I had stripped off the shielding) the shielding, (Green) the performance really moved up a notch or two.  The extra RF in/out helped me debug a few difficult problems as I the program was working OK with a strong signal, and it least gave me a lead where to correct the program.

The core of the coax (Yellow) and the balanced other half of it (Green) makes a simple dipole and connecting it to the earth (the one alongside the signal) and signal on the board made a really huge difference.  The Arduino that I use 24/7 to gather the weather data off the Oregon Sci sensors is fairly well central to all three.  However my development computer is tucked away in a small room with no windows and brick on two sides.  Using this antenna was  really helpful.

Cheers, Rob 
Learning Flute and C++, heading for a meltdown.

robwlakes

Bloomin' .jpeg stopped from sending!!!
I have complained to the webmaster@arduino.cc
I am hoping he/she can help.

Rob
Learning Flute and C++, heading for a meltdown.

Aggertroll

I've changed my code to solve this ... This should be much more robust than before.
I realize this thread is 3 years old, but still:
Kokopa, you are my HERO!

I had an old indoor/outdoor thermometer lying around. Wanted to display the outdoor sensor temp on my iphone via a Wemos D1 (Esp8266), rf sensor and Blynk. (I am quite new to all this, made some wireless power outlets work like that but really struggled with the sensor's signal.)

Found out it was a re-labled OS THR128 which uses OS protocol 1. Found your thread, used your code - and it works!

Thank you! You made my day!

Thomas

robwlakes

This sounds so much more powerful than 3 years ago Aggertrol, how we have all moved on. I have worked out the another OS protocol as well. I am not sure it would be the same as the THR128. I used my Manchester Debugger, it only took a couple of tries and I worked out it is a similar code, underlying data is the same, only running at half speed and has the opposite polarity. I made a matrix temp/humidity/date display for the local hotel to make a "bar talking point" -

https://github.com/robwlakes/Weather_Matrix

It uses the above protocol. I got it to work with the THGN132N and THGR122NX sensors. The Adafruit matrix board (32x16) has a real time clock as well, so that was handy, just add a 433MHz Rx to the system and we were away!

Do you intend to publish your code somewhere? I continue to be interested in this stuff and always on the lookout for new ideas.

Cheers, Rob

 
Learning Flute and C++, heading for a meltdown.

Aggertroll

Do you intend to publish your code somewhere? I continue to be interested in this stuff and always on the lookout for new ideas.
 
Actually, I am using kokopa's modified code pretty much as is and combined it with other functions. I decoded the rf signals of a set of four wireless power sockets (3 are working, one refuses to learn) and am controlling those from my iphone over wifi (Wemos D1 mini, 433 transmitter, Blynk). With the help of this thread I added temperature and battery status from a remote thermo sensor (THR128). All works nicely. But I am a beginner so the code can probably use a lot of cleaning up. I might publish the code in the Blynk forum as an example of "what I made with Blynk". Right now I am trying to get my head around openHAB and understand more about home automation. Want to add switches and sensors step by step.   

Go Up