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?