Opinions on intercepting 433MHz from Oregon Scientific WMR200 Weather Station

Update Update Update: For the latest version of this project please use my GITHub site:

ArduinoWeatherOS for software and hardware updates. eg RGB LED status indicator and design your own sensors.

Historical and Archival relevance follows:

Well it had to happen, my dear old Bios Weather Station has dropped the bearing in the Anemometer and the whole thing is due for retirement immediately. I don't want to buy another cheapy such as the Digitor line, nor go overboard price wise with a Davis System (and for me at least, unknown protocols). The Oregon Scientific stations seems to be a sweet spot in between. Minimum sensors for my setup are - external temperature, wind speed, wind direction and rainfall. The WMR200 ticks those boxes and has the advantage of solar assisted power supply to promote battery life. Arduino suppling air pressure and humidity readings itself.

However, regardless of brand, I do want to definitely keep the strategy of my own Arduino base station intercepting the 433MHz from the OS sensors to provide the interface to my web server. I will just put their LCD version on the kitchen bench.

So what are people's opinions of this line of Weather Station gear in terms of the value/reliability/accuracy trade off??? What is also extremely important is, how successful have been people been, especially in the Arduino community, in intercepting and decoding the Oregon Scientific protocols? I had read some promisinghttp://wmrx00.sourceforge.net/Arduino/OregonScientific-RF-Protocols.pdf www material and GitHub - phardy/WeatherStation: arduino-based decoder for Oregon Scientific weather station, but a bit more detail about analysing the more complex sensor combinations such as the WMR200 would be appreciated.

Rob

PS is there an updated version after the WMR200 around? Is it the WMR300? Does it use the same simple keying (OOK) 433MHz/Manchester protocol? Has anyone had a crack at it? 50% more costly here in Australia and reminds me of a Davis product in style at least.

my_Oregon_15.ino (16.6 KB)

Depends a lot on what you are trying to do.
Its easy to decode the data thats transmitted from Oregon sensors so that you can receive them using an Arduino and then display them on a PC which is connected to the Arduino.
Have a look here.
http://wmrx00.sourceforge.net/
The weather shield is an Arduino based program that can decode the WMR100, 200 series of sensors.

If however , you want to make your own sensors and have them displayed on a Oregon console , then thats a lot harder to do
as there is information in the data that is sent from genuine OS stations that is not fully understood as to its function.
Ive built 2 Arduino weather shield decoders and they work fine .
Ive also made some of my own sensors, mainly temp / humidity ones and they also work fine when used with the Weather shield.

Thank you Mauried for your interest in this topic. That link certainly has some very impressive data processing. My weather site is deliberately simplified, and designed for a simple fisher like me to quickly asses the previous 12 hours of weather and make a decision whether to go out or not. However that does not make the actual decoding of the sensors any easier. So any assistance will be appreciated.

I bit the bullet and bought an Oregon WMR86 for about $220 (Aus) when I could not beat the price down on a WMR200 that was missing CD and Manuals and was a shop window display model. I tried to explain I did not need that stuff but they were only prepared to knock 10% off their price of $450 (Aus). Saying that I am an Arduino programmer and that I was the ideal person to unload this gear on did not have any cred' at all. :0 I did not need the USB+Touch screen features on the WMR200 anyway. The Solar power was the only extra that was really attractive.

I have already reverse engineered an Arduino based Bios weather system program, using the Manchester encoding (Opposite polarity to the Oregon Scientific). I was also able to design my transmitter to it and was much simpler than than the receiver! I am planning a similar extension to the Oregon project already, even though I have not written one line of code, to make up my own outside temperature sensor that my Arduino can detect (same as you I would guess), that also has the full Lithium/Solar rechargeable system built into it as well. The Oregon system on the WMR200 gave me the impression it just took over from the batteries in the day time and the batteries were drained at night time, so it only extended the battery life, and not truly recharged them. Am I correct there?

Thanks for responding, I may ask some help of you soon. I pick up the challenge this afternoon.

Rob

You can cut the costs of OS sensors down by buying them directly from the US.
The prices in Australia are extremely high compared to the US prices.
I use a company called Price USA to do this , as OS in the US wont ship to Australia..
Ive managed to build a clone of a THGR810 temp / Hum sensor which does get decoded Ok on my OS weather stations
and also by a weather shield Arduino based decoder.
Ive got a WMR100 & a WMR80, but its not Arduino based.
Made it long before I learnt about Arduinos.
Its based on a Microchip 16F88 and is written in basic , not C .
Ill eventually get around to a C version.
OS do some funny things to the data that their Sensors transmit, to make it hard for people to make the sensors.
Guess they want to protect their product.

Working WMR86 433Mhz Interception with Arduino
Hi Mauried,
Sorry to be off the air for so long but the brain has tackled the WMR86 V3.0 protocol and I now have a working version. I have used a different approach to the other programs I have seen, in that I use delays to decode the Manchester data, rather than interrupts, counts and limits. Conceptually it is simpler programming, and seeing this is the Arduino's main task, I can keep the interrupts for alternative tasks such as a timer to output my data to my WWW Weather site every minute. I have tried to make this version (below) just a generalised version that other people can easily adapt to the their own needs, just as I am about to do for my own project. I have been able to correct a few things and hopefully not add too many errors of my own. I certainly invite any corrections or helpful suggestions For any one attempting to add extra (arduino or R-Pi etc) receivers to their OS sensors this program should be easy to adapt to their need,s and there is plenty of documentation on protocols, timings, calibrations etc.

I can now have my LCD Base station in the kitchen and the Arduino/Web server in the garage, with no need for messy USB stuff into my Python/Apache2/Ubuntu Server!!!
So it appears I have nearly replaced my old Bios WS with the much nicer kit from Oregon Scientific. These weather stations are very well engineered for the price and I am looking forward to more accurate results.

I will be getting my air pressure and Humidity from interfaces on the Arduino shield (see Photo and schematic below).

Rob

PS Now have my OS-WS "on-air" and happily bedding it in over the Xmas/NY, I will post a listing including internal temp, air pressure and humidity, closer to NY 2014. I was looking for a backup anemometer and noticed OS are discontinuing the WGR800. Now is that true? Have I chosen another endangered species???

hardwired.jpg800×600 114 KB

Schematic.png962×342 50.4 KB

my_Oregon_15.ino (16.6 KB)

Hi Folks,

Just an update. I had a setback with my Oregon Scientific equipment. I noticed the Wind Direction Vane had dropped the LSB bit and was only reporting every even number between 0-15 (N to NNW), so it was operating at half accuracy. My wind direction maps were looking very ordinary with wind never arriving from the odd numbers (eg NNW,NNE etc) and this was creating bands across the map. Obvious to anyone something serious was wrong.

I did not want to take the Anemometer/Direction Vane combo down over the Xmas break (our peak tourist season) and decided to use the range of numbers reported as an average and hence interpolate the directions coming from the odd numbers. At first I used a simple average of the last (rolling) 16 samples recorded, and took its integer value( from 0-15). Suddenly the map was looking good again. Then I remembered why I had not done this before, the cross over region between direction numbers 15 and 0 (ie NNW to N) do not yield good results with just a simple average. eg 8 readings of 15 (NNW) and 8 readings of 0 (N) produces a simple average of 7.5 ie SSE, the opposite direction to what is should be :~

With the help of my son Nicholas, we implemented a "circular average" program in Python, using Sine, Cosine and Atan2. A demonstration Python Code and circular averaging explanation is on this page http://www.laketyersbeach.net.au/windaveraging.html and the resulting map of the wind direction (plus other weather parameters) is on this page Lake Tyers Beach Weather 24/7 Weather. So out of the difficulties comes a much better system.

Why have a wind direction map and not a circular "radar" style graphic? Read here Interpreting Wind Direction Maps.

The graphics indicates the Arduino project with the extra Humidity and Barometer features are working well. I am waiting for rain to check my calibration figures on the rain gauge and I will establish a new thread with all the latest code added. We are in the middle of the Australian summer and rain is a scarce commodity . So if you are waiting, please be patient.

Cheers,

PS Good news is Oregon Scientific (Australia) are replacing the Anemometer/Direction Vane with out any problems, so I bought a back up as well. I am very happy with their support and service.

Nice job! For an alternative exposition on circular mean:

and for higher order directional statistics:

I got Lacrosse/TechnoLine Weather Station WS2355 and also few cheap 433Mhz receivers [1] and antennas for them [2] but I have found out that they have really small range, they work only in same room upto 3m/10ft, anything beyond that they stop receiving data when connected to arduino...

Original WS2355 receiver works through thick indoor walls upto 30m/100ft, which is quite impressive.

This is original receiver in WS2350 weather station, thin wire is antenna:
https://secure.flickr.com/photos/valent_turkovic/13380962533/in/set-72157642850005724

I'm looking for good 433Mhz receivers that I can connect to Arduino and collect data from weather station, but one that has good range, because these ones I got are really bad for anything beyond few meters...

Are there shops that sell finished 433 rx modules, or some ebay shop that sells internationally? Ebay is definitely preferred because of price and also easy worldwide shipping. There are quite few US based shops that have crazy shipping prices, so rest of us outside of US can't use them

[1] http://www.ebay.com/itm/121117930415
[2] http://www.ebay.com/itm/371027094605

You may have conquered the challenges with the Lacrosse (I hope so) , but I would like to add some extra info that I have found out about my Arduino+433Mhz Rx intercepting an Oregon Scientific WMR98 weather station.

I had my weather station dropping out and just giving flat lines on the a graph for hours on end, ie the reception of the Wind Speed/Direction Sensor in particular was borderline reception. However after much, much teeth gnashing I figured out that I had programmed for at least 20 header bits had to be received before being accepted as valid, and this must have been just borderline, as for many days the graphs were great and then for too many times the wind sensor would go "off line" for hours on end and then mysteriously fix itself!!!

By dropping the requirement for a valid header to 15 Bits it has improved the reliability no end. So it would appear that my initial suspicions were right but my solutions were wrong. I was moving the Arduino around to get better reception, and to some extent this was probably working, though only to a very small degree. I believe the requirement of 20 header hits was just marginally inside what was required. When the atmospheric conditions changed and the AGC on the 433Rx changed and therefore reduced the number of valid header hits that could be detected, they had dropped below the threshold, and the Wind data just appeared to drop out!!!!\

So rather than blaming the OS sensor and it RF power or the Arduino+Rx combo for not providing a good RF link, it has been the logic in the program. But the solution was as simple as changing a number from 20 to 15. But still a major revision none the less.

So now it only requires 15 header hits rather than the borderline 20 to validate a header sequence. Maybe only 10 would be better????

In short, from my humble experience, "just check your code" before you blame the 433 connection.

Rob

However I recently added a UV detector from OS and found its RF connection was decidely flakey. It is a well built device and taking it apart was somewhat difficult, but I managed it. After numerous checks and trials of the internals over a number of weeks I concluded the spring wound internal antenna in the sensor housing was made of very stiff wire and had very little give in it. Once I had removed it and replaced it with a 170mm length of hookup wire that exited out of the lower side of the housing, the connection was perfect and quite robust.

The antenna was glued to the body of the sensor and the RF board inside the sensor was screwed to a pannel held in by more screws. My guess is the antenna's conection to the PCB was too rigid had broken the copper track off. As a result it had become an intermittent connection. That is, worked when I had played with it, and gone bad with the hot and cold of outside temperatures.

So just to contradict myself above, sometimes it is the 433MHz connection that needs to be investigated.

Also look up my GitHUB Site for more infor on how to design your own sensors, and add an RGB LED for a status indicator. Very handy for debugging any connection problems, hardware or software.

Cheers, Rob

Hi !

My WMR80 is dead today

Your arduinoWeatherOS is well working but... I have 2 extra THGR810 (thermo/hydro) that are not detected by the software.
Can you help me to modify it ?
Thanks

I should read before to post !!

Modifying the header hits len parameter, TGHR810 is well detected...
Now I have to decode channel to differentiate the probes

Thanks for your work

You are most welcome. It is a pleasure to share. This is one of my most personally rewarding projects.
This another one, a print your own weather station LTB Weather Station by RobWLakes - Thingiverse
Cheers, Rob

Hello Rob,

First, thank you for your great contribution! I'd love to use your code to read wind, temp and RH from a OS WTGR800. I built my hardware using a 433Mhz receiver like this one:

https://create.arduino.cc/projecthub/MisterBotBreak/how-to-communicate-using-433mhz-modules-9c20ed

Put the batteries on my WTGR800, and start monitoring the outputs, and while debugging:

while (digitalRead(RxPin) != tempBit) {

1
}
delayMicroseconds(sDelay);
if (digitalRead(RxPin) != tempBit) {
noErrors = false;
2
}
else {
3
byte bitState = tempBit ^ polarity;
delayMicroseconds(lDelay);
if (digitalRead(RxPin) == tempBit) {
tempBit = tempBit ^ 1;
}
if (bitState == 1) {
if (!firstZero) {
headerHits++;
if (headerHits == headerBits) {
//digitalWrite(ledPin,1);
4
}
}
else {
add(bitState);
}
}
else {
if (headerHits < headerBits) {
noErrors = false;
}
else {
if ((!firstZero) && (headerHits >= headerBits)) {
firstZero = true;
//digitalWrite(ledPin,1);
5

}
Serial.println("Al ADD");
add(bitState);
}
}

I get to the points 1,2 and 3, but I'm not able to get to 4 and 5, shall I try changing any of the Variables for Manchester Receiver Logic?

Any help will be very much appreciatted!
Stay safe!

Hi Disco,

If your code is executing up to 3 but not what is after then it is detecting transitions on the input form the 433Rx, but the transitions are not following the Manchester wavefor protocol and getting rejected. This could mean your signal is non existent and you are listening to noise or maybe the protocol is not compatible. I rigged up a piezo transducer (not a buzzer) across my 433MHzRx first off and listened to the buzzes made by the signal. I could hear the buzz and look for activity on my sensing software to see if it synchronised (and I was making progress).

It your code is completing and stopping at 4 then it is responding to Manchester looking level codes to some degree.

I have looked up another project on the web and it says that your system is Protocol V3

https://weerhuisje.nl/nl/niet-meer-leverbaar/oregon-wtgr800-thermo-hygro-wind-sensor-protocol-3-0/a-9441-88

So it should be possible to test it with code/project that I have at:

It has the full OS V3.0 decoding (as best as I knew at the time) so should give you a leg into solving this problem. However when you use it you will need to defeat this "IF" block

Line 641 if ((scan&7)==7) {

Just change it to if (true) { so that the test no longer matters.

This test was added so that the Arduino would not report back any readings until it had logged all of the sensors (it is waiting for three sensors here bit mapped flags ie temp/Hum, Wind Speed/Direction and rainfall). This delayed startup for a maximum of 45 seconds as the rainfall sensor had the longest delay between transmissions. It meant when the Arduino sent off a CSV string back through the USB/Serial connection to the Raspberry Pi, all the signals that were graphed by the RPi were valid and I did not suddenly get readings of zero air pressure for example (not so good!!)

I have not known of the existence of this wtgr800 system. It looks very compact and well designed. If you use this code it provides the mathematical calculations for the different sensors as well. OS Sell their rain gauge on its own so you could add that for a full system.

I have since worked out a better algorithm that is based on a module for getting bits and the calling module for assembling them into bytes (this is the one you are looking at with "addbitstate()" in it). It makes the Manchester idea so much easier to follow. I should really update all of them, but I find Git-Hub a real pain to do anything confidently with. So the one I have recommended above to try and at least use it for the OS protocol and structure of the data packets to help you unravel your particular model.

My system has three separate sensors Temp/Hum, Wind Direction/Speed and Rainfall (plus now UV) so involves a seperate 433Tx in each and each has its own protocol, byte/bit length etc. So the Arduino+433Rx listens and decodes all of them. If they collide it just sees an error and waits for another try. They have different durations between their transmissions, so they only collide very now and then and within the next minute it should be ok. Seeing your system combines Temp/Hum/Wind Speed/Direction, it may have its own protocol, ie put it all into one packet?? You may have tinker with it considerably to get it right.

Things to to try once you are sure you are getting a header and the first start bit is to defeat the error checking and extend the number of bits to see what data you are collecting. Use HexBinDump to printout the contents of the receive buffer (which you have to enlarge) to see if you can find data patterns that change when you change the sensors, eg spin the anemometer by hand, or choose another direction.

Sleuthing these things can be great fun (beats Crosswords and Sudoku hands down each time, it actually does something!!!) and will be very keen to see you get it working and maybe share the results of your findings with me. I am very curious about your sensors!!!

Cheers, Rob

PS Your receiver is a regenerative receiver, a super regenerative receiver is better as it gives greater sensitivity and better noise reduction. But if you are using yours at close range at the moment for testing purposes it should be fine. I did all my preliminary testing with one.
https://www.ebay.com.au/itm/433Mhz-Wireless-RF-4Channel-Output-Receiver-Module-and-Transmitter-EV1527-JO/264680686468?hash=item3da032c384:g:Ae0AAOSwUYhcYNcR
Where the Tx and Rx have crystals on the board rather than manually tuned coils are better.

Hi Rob!

First thank you so much for your prompt response, it's very kind of you taking the time to review my issue!

I have been following your advice, I were able to get to points 4 and 5; it also calls the add() function. But the only values I get are:

One second ...0,0,0.0,0.0,0.00,0.00,2.34,nan,0,0,0

I've been digging deeper: as mentioned, it enters to the add() function, it also enters to the else block here:

void add(byte bitData) {

Serial.println("POINT>> 10 Enters add()");
 if (discNos > 0) {
   discNos--;//discard bits before real data

Serial.println("POINT>> 11 - add() -  if (discNos > 0) {");    
 }
 else {   <<<<<<<<<<<ENTERS HERE

And sometimes here:

Serial.println("POINT>> 12 - add() -  else {"); 
   //the incoming bitstream has bytes placed in reversed nibble order on the fly, then the CS is done.
   if (bitData) {
     //if it is a '1' OR it in, others leave at a '0'
     manchester[nosBytes] |= oregon[nosBits];//places the reversed low nibble, with hi nibble, on the fly!!!
Serial.println("POINT>> 13 - add() - if (bitData) { "); 
     
   }

but it never enters to any of these:

if (manchester[0] == 0xA2) {
     maxBytes = 11; //rain
     csIndex = 19;
   }
   if (manchester[0] == 0xA1) {
     maxBytes = 10; //wind
     csIndex = 18;
     Serial.println("Wind S detected");
   }
   if (manchester[0] == 0xAF) {
     maxBytes = 9; //temp
     csIndex = 16;
     Serial.println("Temp S detected");
   }
  if (manchester[0] == 0xAD) {
     maxBytes = 8; //UV Light Detector
     csIndex = 14; //CS byte begins at 14 nibble
   }
   if (manchester[0] == 0xA3) {
     maxBytes = 10; //experimental, Solar,Strikes,UV
     csIndex = 18; //CS byte begins at 18 nibble
   }

Hence I'm wondering if maybe the issue is that my sensor may have a different Hex code... Where do those codes come from?

Checking one of your sources (http://wmrx00.sourceforge.net/Arduino/OregonScientific-RF-Protocols.pdf) I found in page 10 all known Sensor ID Codes; my device is the WTGR800 and while is not specifically in the list, there is a WGR800 that includes a temperature/RH sensor; hex code = 1994 but the format seems to be different from the two digits hex codes from this block of code... So how shall I format it?

Also is there a way to find the right values for the

maxBytes

and

csIndex

of my sensor, or just trial and error?

It never gets to this code:

 if (nosBytes == maxBytes) {
Serial.println("POINT>> 14 - add() -   if (nosBytes == maxBytes) {"); 

      hexBinDump();
      digitalWrite(ledPin, 1);
      Serial.println("WCheck SUM");
      //Check Checksum first
      if (ValidCS(csIndex)) {
        //Process the byte array into Human readable numbers
        analyseData();
      }
      noErrors = false; //make it begin again from the start

I really hope to get my sensor up and running, I'm looking forward to start extending my station with more of the OS great devices...

I will get a new Rx like the one you recommend ASAP, for now I have my sensor close to the RX.

Once again thank you for your help!
Javier

Hi Javier,

Glad to help. Corona Virus is making me feel very useless at the moment so this is a welcome distraction.

That reference I put in my GIT-Hub posting (OregonScientific-RF-Protocols.pdf) with some reluctance as the manner in which he talks about Manchester logic is some of the most convoluted way of thinking. Manchester encoding is very simple if the language around it is kept simple and he confabulates most of it. How he got anything to work amazes me. However it is worth a read, just to reassure ourselves it can be done.

First let's just revise some OS packet basics:

1. First we have a stream of 1's, these cannot be sure to be 1's until the first 0 turns up.

2. OS packets use the first synchronising zero bit as part of the first byte, it is counted into the data bytes.

3. Therefore the raw first byte (Station Identifying Byte) will always begin with a zero.
   (some protocols discard this 0). Set HexBinDump() to help debugging.

4. Using the Wind detector WGR800 as an example the bit stream appears as follows
   a. A string of 1's makes the header (stabilizes the AGC and level detector)
   b. First zero arrives, start packing this and all following bits into bytes ie add(byte bitData)
   c. The raw bit pattern that the Rx sees (including the first zero) is 01011000 for the first byte
   d. OS protocol reverses the order of bits in every 4 bit nibble throughout the whole packet.
   e. So the Rx sees raw ABCDEFGH bits, and then OS uses them as DCBAHGFE.
   f. My program applies this to all the bytes in the packet, otherwise the actual wind speeds and directions are "hidden" and very hard to recognise.
   g. To simplify my program I apply this nibble reversal to the Station ID as well.
   h. So the station ID byte is received raw order 0101 1000, but I store it as 1010 0001 or hex A1
   i. So all subsequent station checks are against the reversed Nibble order rather than the raw order received.
   j. This means all station IDs are in reverse Nibble order and will have the XXX0XXXX make up, as that 0 is the necessary and included synchronising bit.
   k. When you have the packet in reversed nibble order you will be able to read the weather data inside the packet so much easier and determine what is what.

5. The reverse Nibble arrangement is achieved by using a simple lookup array to add the bit into the right position in the right order. oregon[] is an indexed array.
   a. So the 8 byte masks are in this order 0001 0000, 0010 0000, 01000 0000, 1000 0000, 0000 0001, 0000 0010, 0000 0100, 0000 1000 or 16, 32, 64, 128, 1, 2, 4, 8
   b. So every byte received has this transformation applied, even the Station ID. To me this is the true station ID, not whatever is in that PDF.

6. When the station ID is detected it means the length of the packet can be associated with it and how many bytes (and therefore nibbles) can be expected. The required number of bytes means any thing shorter or longer is received, it is an error and gets dumped. You will need to find the number of bytes though first by trial and error first, then you can check it when you are ready. As long as you know what the station ID is don't worry what anybody else calls it.

7. The byte after the Station ID is usually a random (rolling 8 bit) number assigned when the power is applied to a sensor. I generally don't check this as usually most people just want to run one version of a sensor and they are the only people doing in the neighbourhood. However if you wanted to receive multiple sensors of the one type this would be important. Don't use it though if you don't have to, as that will mean you don't have to reset your receive program every time you change batteries!

8. The Protocol 3.0 has a simple checksum based on adding the nibbles into a number and storing it as the last byte in the packet. This may or may not be an even number of nibbles, so when you get an idea of where the actual weather data is in the packet, what is left over is probably the check sum. You will need to turn off this checksum checking to begin with until you are ready. CSindex is set to a known value once each Sensor ID is established. ie it is how many nibbles (not bytes, it may be an odd number) are included in the checksum.

9. You will also have to experiment with how many bytes are in the checks as well to see if you have collected all the data. If you are using the BinHexDump() routine you will get an idea from the steady data early in the packet. Be careful though if you make the number of bytes expected in the packet too long you will stop receiving the packet, and receive noise as malformed Manchester bit patterns. This will cause the program to exit and not allow you to process the data at all. So increase the number of bytes slowly and see what happens. This is what maxbytes refers to.

10 When you can receive a stable packet, and push it into HexBinCode() you will be nearly there.

11. I found the nibble formats for the Temp, Humidity, Wind Speed and direction followed fairly closely what other people had found in other OS sensors, so have a close look at how my calculations are derived. You should have the console to check your suspicions against to see if you have interpreted right. eg which byte changes when you move the direction vane and what does it say on the console?

12. Use HexBinDump() as you progress. It takes time to the do the dump (use Baud 115200, or as high as possible), so use it sparingly and move it further along the processing chain as you make headway.

I hope this helps and gets you further along the discovery trail.

RobW

PS I presume you have the check turned off that it will not do anything until 3 sensors have been found? Line 641?

Hey Rob,

Wow, thank you! I've read carefully all your explanations and I'm trying to understand the logic. I have to admit it's not easy for me...

Yes, check sum is disabled, as well as the "if ((scan&7)==7)" condition.

Findings:

While in the add() function, I never reach to meet if (nosBytes == maxBytes); so what I did was forcing executing hexBinDump() at the end of the function.

I'm not sure if this is any useful; I get mostly 0s, but for the first byte I'm sometimes getting a value, some of these values repeat, being 40 the most common, sometimes I get 00 or random values, which I think it's OK, my biggest concern is about the rest of the bytes being always 0.

Another exception is the last byte, that seems to be following a sequence, 0, 1, 2, 3 back to 0, some times up to 7, but most of the time follows the sequence (or repeat 01)

I attached a serial monitor capture, just in case you can have a look to it.

Do you think is there any reason to be a hardware issue?

Big, big thank you Rob, this project means a lot for me!
Greetings from Spain!
Javier

Output 2.txt (18 KB)

Hi Javier,

Glad to hear you are hanging in there and not giving up....

This bit of code below is the start of the add() routine. It is supplied with a bit stream where it packs bits into the bytes in the byte array manchester[]. It also checks the first byte in the manchester[] array for a station ID. I have included as an example the rainfall one with an ID of hex A2. The program cannot determine what the Station ID is until the whole byte is received, once it has done that though, the program can establish the number of bytes for that particular sensor and the number of nibbles used in the Checksum (these have been found out by trial and error previously, not calculated from the station ID).

void add(byte bitData) {
  if (discNos > 0) {
    discNos--;//discard bits before real data, we don't discard the first zero, we include it
  }
  else {
    //the incoming bitstream has bytes placed in reversed nibble order on the fly, then the CS is done.
    if (bitData) {
      //if it is a '1' OR it in, others leave at a '0'
      manchester[nosBytes] |= oregon[nosBits];//places the reversed low nibble, with hi nibble, on the fly!!!
    }
    //Oregon Scientific sensors have specific packet lengths
    //Maximum bytes for each sensor must set once the sensor has been detected.
    if (manchester[0] == 0xA2) {
      maxBytes = 11; //rain
      csIndex = 19;
    }

This stream of bits then packed in with this a bit further down

    nosBits++;
    //Pack the bits into 8bit bytes
    if (nosBits == 8 ) {
      nosBits = 0;
      nosBytes++;
      manchester[nosBytes] = 0; //next byte to 0 to accumulate data
    }

The maxBytes variable is initialised with a starting value of 9, this is long enough to ensure the reading starts, but as soon as the Station ID is recognised the appropriate maxBytes is assigned a proper value. We are chasing an unknown maxBytes and csIndex.

So before the checksum routine listed below add these lines...........

if (nosBytes == 5){
   //checkout the raw manchester array with no processing
   hexBinDump(); //see how we are going at this point
   eraseManchester(); //this array must always be zeroes at the start of a new run
   noErrors = false; //make it begin again from the start
}

You may have to make "5" as low as 2 to begin with.

This will dump out the progress of the incoming data, but only when at least 5 bytes has been received (ie not when every bit is added, that is too disruptive). If you can get a stable pattern after tuning things up then you could increase the number upwards from 5. Because nosBytes now never reaches maxBytes ie 9 then it won't try to do a checksum check either. (NB You may have to change that maxBytes=9 later if you need a bigger packet, but by then you will be defining it in this loop anyway).

    //Check the bytes for a valid packet once maxBytes received
    if (nosBytes == maxBytes) {
      //hexBinDump();
      digitalWrite(ledPin, 1);
      //Check Checksum first
      if (ValidCS(csIndex)) {
        //Process the byte array into Human readable numbers
        analyseData();
      }
      noErrors = false; //make it begin again from the start
    }
  }
}

I am worried that the assumption that the sensor uses V3.0 protocol. Have you found that referred to on the box or the instructions for your sensor? I have bought a combined temperature and humidity sensor only to slowly discover the protocol was different. The data rate was half the speed and the logic of the protocol was inverted compared to the V3.0 protocol. Took a long time to discover that. I had assumed it must be V3.0.

If you are getting the add(0 routine you must be at least getting a header, and finding the synchronising zero, what we need now is steady data in that manchester[] array, just looking at the first few bytes will help zoom in on the next part to focus on.

Keep up the good and keep our minds sharp. I feel like I am playing chess with a blindfold 8) at the moment, but we will get there.

RobW

Thanks Rob!!!

I just read it and I'm going to test now, just wanted to confirm that this device uses protocol v3.0 as you can see in the attached picture.

Looking forward to make progress!!
Javier

IMG_20200427_104930.jpg4608×2592 711 KB