Fine Offset WH1081 (Maplin N96GY) sensors working on Pi

... when I try to run the executable using ./weatherlogger , I get the following errors:

Code: Select all

Failed to open /dev/mem, try checking permissions.
Failed to map the GPIO registers into the virtual memory space.

It's most likely just file permissions - look at the output of 'ls -l /dev/mem'. If you run the program as 'sudo ./weatherlogger', it will run with the appropriate permissions.

The file /dev/mem allows access to parts of memory that can completely crash a system, so it's protected from access by default.

... when I try to run the executable using ./weatherlogger , I get the following errors:

Code: Select all

Failed to open /dev/mem, try checking permissions.
Failed to map the GPIO registers into the virtual memory space.

It's most likely just file permissions - look at the output of 'ls -l /dev/mem'. If you run the program as 'sudo ./weatherlogger', it will run with the appropriate permissions.

The file /dev/mem allows access to parts of memory that can completely crash a system, so it's protected from access by default.

'sudo ./weatherlogger' gives me the error: "Failed to open device: No such file or directory"

... when I try to run the executable using ./weatherlogger , I get the following errors:

Code: Select all

Failed to open /dev/mem, try checking permissions.
Failed to map the GPIO registers into the virtual memory space.

It's most likely just file permissions - look at the output of 'ls -l /dev/mem'. If you run the program as 'sudo ./weatherlogger', it will run with the appropriate permissions.

The file /dev/mem allows access to parts of memory that can completely crash a system, so it's protected from access by default.

'sudo ./weatherlogger' gives me the error: "Failed to open device: No such file or directory"

Right...I'm getting somewhere! I had to load modules spi_bcm2708 and spidev. Now when I run sudo ./weatherlogger, I see the following:

Code: Select all

 $ sudo ./weatherlogger
  LNA_0,RSSI_73 idx 0     0.00    0.00    0.00    0.00    0.00    0.00
  LNA_0,RSSI_79 idx 1     0.00    0.00    0.00    0.00    0.00    0.00
  LNA_0,RSSI_85 idx 2     0.00   12.23   97.85  100.00  100.00  100.00
  LNA_0,RSSI_91 idx 3   100.00  100.00  100.00  100.00  100.00  100.00
  LNA_0,RSSI_97 idx 4   100.00  100.00  100.00  100.00  100.00  100.00
 LNA_0,RSSI_103 idx 5   100.00  100.00  100.00  100.00  100.00  100.00
  LNA_6,RSSI_73 idx 6     0.00    0.00    0.00    0.00    0.00    0.00
  LNA_6,RSSI_79 idx 7     0.00    0.00    0.00    0.00    0.00    0.00
  LNA_6,RSSI_85 idx 8     0.00    0.00    0.00   43.17   95.74   80.11
  LNA_6,RSSI_91 idx 9    98.41  100.00  100.00  100.00  100.00  100.00
  LNA_6,RSSI_97 idx 10  100.00  100.00  100.00  100.00  100.00  100.00
 LNA_6,RSSI_103 idx 11  100.00  100.00  100.00  100.00  100.00  100.00
 LNA_14,RSSI_73 idx 12    0.00    0.00    0.00    0.00    0.00    0.00
 LNA_14,RSSI_79 idx 13    0.00    0.00    0.00    0.00    0.00    0.00
 LNA_14,RSSI_85 idx 14    0.00    0.00    0.00    0.00    0.00    0.00
 LNA_14,RSSI_91 idx 15    0.00    0.00    0.00    0.00    0.00    0.00
 LNA_14,RSSI_97 idx 16   47.59< 100.00  100.00  100.00  100.00  100.00
LNA_14,RSSI_103 idx 17  100.00  100.00  100.00  100.00  100.00  100.00
 LNA_20,RSSI_73 idx 18    0.00    0.00    0.00    0.00    0.00    0.00
 LNA_20,RSSI_79 idx 19    0.00    0.00    0.00    0.00    0.00    0.00
 LNA_20,RSSI_85 idx 20    0.00    0.00    0.00    0.00    0.00    0.00
 LNA_20,RSSI_91 idx 21    0.00    0.00    0.00    0.00    0.00    0.00
 LNA_20,RSSI_97 idx 22    0.00   13.23   98.39  100.00  100.00  100.00
LNA_20,RSSI_103 idx 23  100.00  100.00  100.00  100.00  100.00  100.00
starting main loop


It seems to hang at "starting main loop". What is my next step?

Many thanks.

That's good output - you want to choose an output with 0.00 on it anything else - like the 100's are showing interference.

Try using LNA_6,RSSI_79

Also, look back in this post as Kevin explains more about the noise etc and whats best to do. He also explains about how to you the test mode by putting any argument on the command line - that way you can see the number change from 0.00 which will show your receiving some data.

if you start seeing ful stops - thats good - it means your recieving 'something' - its then just a matter of fiddling with the lna, rssi etc settings until it starts decoding.

0x958A, 0xA67C, 0xE105, 0xCC0E, 0xC69F, 0xC46A, 0xC813, 0xC206, 0xC080, 0xCE84, 0xCE87, 0xC081

As best I can tell this is for 868.3MHz, load capacitance 12.5uF and bandwidth 134kHz, RX LNA 0dB with -103dBm RSSI. The only thing that looks odd is the data rate given by '0xC813'.

I also thought the data-rate calculation came out with an unusual number (I got 17.24 kbps), but it's as valid as any, I suppose. I wonder if it's a function of the master's SPI bus speed - e.g. to allowing enough time to fetch the FIFO before the next bit comes in (which would otherwise cause a FIFO overflow).

It looks like the FIFO interrupts on 8 bits full - I guess it would be enough to watch a GPIO connected to FFIT or nIRQ and then pull the FIFO contents via SPI.

I put the decoded configuration values on a page here - http://www.susa.net/wordpress/reference ... iguration/ - there might be errors....

Kevin:
I've written a small test program using the power-on values from @cii (adjusted for my 915MHz module). The IRQ is connected to GPIO22 and generates an interrupt every 48 seconds (actually a few interrupts). So far so good ...

... watch a GPIO connected to FFIT or nIRQ and then pull the FIFO contents via SPI.

Sounds easy enough, but I have no idea how to "pull the FIFO contents via SPI". Any help here is appreciated.
Cheers
Karl

Sounds easy enough, but I have no idea how to "pull the FIFO contents via SPI". Any help here is appreciated.

If you look at the code that reads the status byte from the module (in the sample-rssi bit of code, I think), you'll see that it reads a single byte. However, the datasheet states that following the status byte will be the FIFO contents.

You should be able to copy that bit of code, and read two bytes rather than just one. The first will be the status (which itself will contain useful information, such as FIFO overflow bit etc.), and the second will be the 8 bits that were clocked into the FIFO (and that resulted in the interrupt being generated).

Thanks to the info on this page/forum, particularly the SPI set up from cii on his Clas Ohlson WH1080 (which is what I have) I have now managed to acquire the radio data with a RFM12 and interpret some of it. BTW, don't hate me, but I'm doing this on a PIC, but it all reads across.
There is a lot missing in the data sheets, and by looking at the pi code and others, and a lot of trial and error, I'm getting reliable info.
First. SPI setup
send_command16( 0x82d8 );
send_command16(0x80e8 ); //Power Management - turn it on
send_command16( 0xA67C); //freq 868.300MHz
send_command16( 0xC49f);//
send_command16( 0xC2ec ); //
send_command16( 0xC613 ); //data rate 17.241 kbps
send_command16( 0xC006 );//low bat and uc clock
send_command16( 0x97A0); //ok rx cnt LNA Gain max dBm RX Bandwidth 134 kHz Pin VDI fast DRSSI 103 dBm a2 is rssi 91bd
send_command16(0xCA81);//data states bit 1 must be cleared and reset to restart synchron
send_command16(0xCA83); //reset FIFO and read to receive next Byte

You have to set up with SPI speed at 5Mhz, then switch down to 2.5Mhz to receive the data (using the 0xb000 command). It's critical to do 2 status reads before you engage interrupts. I'm using the nFFS pin as interrupt, with FFIT pulled high with a 1k. Once you've received (I'm taking 33 bytes, but I'm not convinced they are all used) you need to push the speed back up and do a status read, plus the last 2 lines above ie ca81, ca83.
My data stream over SPI looks like this :-
00 A8 C0 12 5C 00 01 03 89 02 65 00 15 55 55 45 BA 95 18 02 4B 80 00 20 71 20 4C A0 02 AA 00 00 00
So far I've worked out byte 3 - 12 is the temperature *10, so currently 1.9C. I suspect the previous nibble is the sign. Next one, 5C is humidity 92%, next one 00 is wind speed *.34 , skip 4 to 02 is direction- starting at 00 as north, looks like they go clockwise, ending at 0x0f.
The receiver is breadboard mounted 82mm aerial next to a 40Mhz pic, hooked to a scope, about 15m from the outdoor sensor through 2 walls, but gets every packet.
I am going to try messing around with the status read ie 0x0000 to read the fifo, as this is done at full speed, plus wait for some wind and rain to work out the rest. There seem to be a lot of variants of these systems, with different frequencies, setups and interpretations...
Hope this helps.
Good fun though..

Good stuff, the data looks great. Using a PIC as a buffer is something I've considered for the Maplin unit - with a 2 x I2C and 1 x SPI MCU, it could act as an I2C slave to the Pi, and we'd avoid any issues with timing (Linux etc.). USB could also be an option.

You have to set up with SPI speed at 5Mhz, then switch down to 2.5Mhz to receive the data

Does this have to run at 5MHz, or could the bus be left at 2.5MHz for all SPI? (e.g. is a higher speed necessary to prepare things quickly enough for reception?)

So far I've worked out byte 3 - 12 is the temperature *10, so currently 1.9C. I suspect the previous nibble is the sign.

There must be other bits involved, or else 25.5 degC would be the maximum recordable temperature. Also, I guess a big chunk of the data will be date/time (DCF-77 or similar) - I'm sure I found a page relating to this data on Fine Offset stations, but I've not been able to re-locate it.

I'm using the nFFS pin as interrupt, with FFIT pulled high with a 1k.

Did you write these the wrong way round? (e.g. instead of nFFS pulled high, FFIT used as interrupt).

Also, what's command 0xb000? I can't find any command in the datasheet that starts with bits '1011'.

Sounds easy enough, but I have no idea how to "pull the FIFO contents via SPI". Any help here is appreciated.

However, the datasheet states that following the status byte will be the FIFO contents.

Actually, having been looking at the datasheet, it's two status-bytes that get returned before the FIFO data - my mistake.

You have to set up with SPI speed at 5Mhz, then switch down to 2.5Mhz to receive the data

Does this have to run at 5MHz, or could the bus be left at 2.5MHz for all SPI? (e.g. is a higher speed necessary to prepare things quickly enough for reception?)

So far I've worked out byte 3 - 12 is the temperature *10, so currently 1.9C. I suspect the previous nibble is the sign.

There must be other bits involved, or else 25.5 degC would be the maximum recordable temperature. Also, I guess a big chunk of the data will be date/time (DCF-77 or similar) - I'm sure I found a page relating to this data on Fine Offset stations, but I've not been able to re-locate it.

I'm using the nFFS pin as interrupt, with FFIT pulled high with a 1k.

Did you write these the wrong way round? (e.g. instead of nFFS pulled high, FFIT used as interrupt).

Also, what's command 0xb000? I can't find any command in the datasheet that starts with bits '1011'.

Last night I tried doing it all at 2.5Mhz and got nothing useful. 10MHz setup is fine, with 2.5Mhz to receive data. Lower than 2.5M didnt work. I can't get any sense out of the status word 0x0000 for the FIFO output. The Hope examples in C show it should work, and I'm sending the correct extra 8 clocks, but no output. It is possible that I'm checking too quickly after the interrupt. I'll tinker a but more as it's more useful to have the SPI running at one speed, especially as I'm running other devices on it.
Yes, 25.5 would be a bit limiting. In my excitement I overlooked this, but in my defense it did occur to me this morning. The next nibble to the left must be the sign bit and the rest, allowing +/- 204.8C It got down to 0.5C last night so I never found out the sign bit. Soon.
B000 is the fifo read. It's on page 18 of the IC datasheet, before AFC, and after synchron pattern.
I'm not convinced that DCF info is sent. Or pressure. I think they are both built into the base unit, as I got both of these on the display without batteries in the transmitter.
I didnt write them the wrong way around, I simply wrote them incorrectly. nIRQ is the interrupt, nFFS pulled high. Oh FFS. It was late, I was tired.... I've just checked on the scope and FFIT is the complement of nIRQ. nIRQ goes low to alert you.
And CRC is present on first 9 bytes, with the result in the 10th (thanks to http://www.susa.net/wordpress/2012/08/r ... nd-rfm12b/) for finding that one, and most of the rest.

Actually, having been looking at the datasheet, it's two status-bytes that get returned before the FIFO data

Yes, since the return value of the send_command16() function is only used for the status command, I've changed it to return 4 bytes (uint32_t), the first 2 bytes holding the status register, the 3rd byte holding the FIFO and the last byte always 0. As @cii and @avago suggested, the read loop captures 33 bytes. Here is some output:

Code: Select all

07:34:51 a0 38 3d 1b 00 00 00 00 08 fe 00 15 55 55 05 9a 96 07 07 ab 60 00 00 00 01 1f c0 02 ea ab b8 b7 12
07:34:51 80 38 3d 5b 00 00 00 00 08 be 00 15 15 5d 45 ba 84 07 07 ab 60 00 00 00 01 07 c0 03 ae aa b8 bf 52
07:34:51 80 3c 3d 5f 00 00 00 00 08 fe 00 00 00 ed ff bf 8f 49 e1 38 66 f0 bc c4 1b aa cb 27 19 f8 f0 9f d8
07:35:39 a0 18 3f 5f 00 00 00 00 0c 7a 00 17 51 55 45 bb 94 07 07 a3 20 00 00 00 01 8f 00 00 ba a8 a0 97 52
07:35:39 e0 38 3d 5b 00 00 00 00 0e 7a 00 1d 55 55 45 fa 84 07 07 ab 70 00 00 00 01 87 40 03 8a aa a8 b7 52
07:35:39 e0 38 3d 5b 00 00 00 00 0c 7a 00 00 03 b8 28 1f df e5 dc e2 80 0f 32 e7 23 7f 18 8b 13 4c d1 3e 77
07:36:27 a0 38 3d 5b 00 00 00 00 0a dc 00 11 15 55 45 bb 96 07 07 8b 20 00 00 00 01 1b 80 02 aa aa a8 f7 52
07:36:27 e0 38 3d 1b 00 00 00 00 0e cc 00 15 45 55 41 fa d4 07 07 a3 60 00 00 00 01 5b c0 02 ae ae a8 b7 52
07:36:27 a0 38 3d 59 00 00 00 00 0a dc 00 00 00 8a c0 fb e3 d7 f7 fb 08 11 ff fb fd bd e3 ff cf 12 02 cf 71
07:37:15 a0 38 3d 5b 00 00 00 00 0c 7e 00 17 55 55 44 fa 90 07 07 bb 20 00 00 00 01 8f 60 02 aa aa a8 f7 52
07:37:15 a0 38 3d 5f 00 00 00 00 0c f4 00 45 5d 51 6e a1 01 c1 ee d8 00 00 00 00 c7 a0 01 55 75 54 5b e9 40
07:37:15 a0 38 3f 4b 00 00 00 00 0c 7e 00 00 01 ee a6 20 c9 16 08 17 d7 3c 0f 5e f8 b0 01 98 e0 78 77 f0 62
07:38:03 e0 38 3f 5b 00 00 00 00 0a dc 00 17 51 51 45 fa 9c 07 07 a9 60 00 00 00 01 5b 80 02 a8 aa a8 bf 72
07:38:03 a0 38 3d 7b 00 00 00 00 0a fc 00 15 55 55 65 b8 94 07 07 ab 60 00 00 00 01 5b 80 03 aa a2 a8 b3 53
07:38:03 a0 38 3d 5f 00 00 00 00 0a dc 00 00 02 7f f1 0b f0 0f 10 51 1f f6 c2 c3 65 9b ef b1 fe 89 3f ef 8f
07:38:51 e0 3c 3d 5b 00 00 00 00 0a dc 00 15 57 55 45 ba 94 03 07 ab 60 00 00 00 01 7b 80 02 ea a8 b8 b7 72
07:38:51 e0 e0 f1 6c 00 00 00 00 23 70 00 57 5d 55 12 fa 50 1c 1e ac 80 00 00 00 05 6e 00 0e ab ae a2 dd 6a
07:38:51 a0 38 3d 5b 00 00 00 00 0a fc 00 00 02 19 87 20 a3 71 9f 87 eb f1 98 b8 13 ea 21 90 bb 1b 7f 25 8c
07:39:39 a0 38 3d 5b 00 00 00 00 00 07 00 05 55 15 44 ba 90 07 07 ab 60 00 00 00 00 00 e0 00 aa a2 a8 b7 52
07:39:39 e0 38 f5 6c 00 00 00 00 00 1c 00 51 55 5d 1e ea 10 1c 1e ad 80 00 00 00 00 03 80 0a ab ba a3 dd 4a
07:39:39 e0 3c 3d 5b 00 00 00 00 00 07 00 00 00 25 48 b7 f0 11 7e f0 b7 fd 3c 80 2f c1 43 67 b3 c1 f1 31 87
07:40:27 e0 38 3d 5b 00 00 00 00 08 9e 00 15 55 55 45 fa 9c 07 07 ab 60 00 00 00 01 07 c0 02 ab aa a8 bf 5a
07:40:27 a0 38 1d b6 00 00 00 00 10 7c 00 2a 8a aa 8b 77 2c 06 0f 57 c0 00 00 00 03 2f c0 05 57 5d 51 2e a5
07:40:27 a0 38 3d 5b 00 00 00 00 08 be 00 00 01 97 7b 80 3b f8 09 3c 9f 23 9b fc 4c 4c 77 87 b7 67 33 f2 fc
07:41:15 a0 38 3d 5b 00 00 00 00 0a dc 00 1d 54 45 41 ba 94 07 03 ab 60 00 00 00 01 1b 80 02 aa ba a8 b7 52
07:41:15 a0 38 3f 5b 00 00 00 00 2b 70 00 75 55 57 16 ea 10 1c 1e ac 80 00 00 00 05 66 00 0a ab ab a2 dd 4b
07:41:15 a0 38 3c 7b 00 00 00 00 02 70 00 00 0e 7e 61 3f 90 1f 04 21 f9 fa 7e 3a 5f cb 00 84 7b a1 bc 40 50


I haven't tried to decode it yet, but those were the current conditions: -6.1°C Temp, 91% RH, 0 kmh Windspeed, 225° Bearing. Although I receive every 48s, my SPI setup might still be wrong, i.e. I don't know the exact frequency the TX uses, so I have set the receiver to 915.0 MHz ...

Also, what's command 0xb000? I can't find any command in the datasheet that starts with bits '1011'.

Please note that @avago is using a RFM12B, the command 0cb000 is the "Receiver FIFO Read Command"

I can't get any sense out of the status word 0x0000 for the FIFO output.

This post (http://forum.jeelabs.net/node/1455) suggests that, regardless of whether 0xb000 or 0x0000 is used, the FIFO bits in the stream have to be read at <= 2.5MHz.

@KarlS Looks like the transmitter is sending the same message 3 times, as they are pretty similar? I only receive one set. The humidity figure seems ok ish (varies over the 3 messages), but I'd say that you have bit errors. Also the CRC didnt work out over the first 9 bytes. The temperature looks like 0x3d, with the 8 in the previous nibble being sign?

It's good to get something, so you can now tinker to improve. It's so soul destroying when you get nothing!

@avago Thank you for your moral support, my wife thinks I'm crazy ...

The humidity figure seems ok ish [...] but I'd say that you have bit errors

That's what I believe too. I check the status byte after each read and accept only values that have '1000' in the high nibble, meaning the FIFO is full and no overflow occured. As I said, my SPI configuration may not be optimal. I think finding the correct TX frequency would be a big step forward. However with no scope or frequency scanner (not that I knew how to use them) there will be a lot of try and error necessary.

@avago Thank you for your moral support, my wife thinks I'm crazy ...

The humidity figure seems ok ish [...] but I'd say that you have bit errors

That's what I believe too. I check the status byte after each read and accept only values that have '1000' in the high nibble, meaning the FIFO is full and no overflow occured. As I said, my SPI configuration may not be optimal. I think finding the correct TX frequency would be a big step forward. However with no scope or frequency scanner (not that I knew how to use them) there will be a lot of try and error necessary.

The AFC offset value that's returned in the status bytes will give you an indication of how far off the centre frequency your receiver has to go for the signal. It'll be 'offet' multiplied by 7.5kHz for your 915MHz configuration. Based on my original code, something like this might do: -

Code: Select all

void get_frequency_deviation(int fd) {

   send_command16(fd, cmd_afc & (~AFC_ON)); // Disable AFC processing
   uint16_t status = send_command16(fd, cmd_status);
   // get offs bits and extend two's complement to a byte
   int8_t offset = (status & STATUS_OFFS) | (status & STATUS_OFFSIGN ? 0xe0 : 0);
   
   float freq_offs = (float)offset * 7.5f;

   send_command16(fd, cmd_afc); // Re-enable AFC

   printf("Frequency deviation %0.1fKHz (%d)\n", freq_offs, (int)offset);
}

However, I'd be more tempted to play around with the bitrate setting (Data Rate Command in datasheet). It could be that Fine Offset calculate it as a function of the transmit frequency. Try R = one of 17, 18, 20, 21. Maybe also try changing the clock-recovery setting (Data Filter command) to see if it makes a difference.

I'd expect at least three nibbles of data (station id) near the start of the stream to be identical on each packet (though they can change if you power-cycle the transmitter).

Lastly (and unrelated), I'm sure that, from the photo you posted, there's a DCF-77 antenna in your transmitter. If so, then some of the bytes you're receiving will certainly be date/time data.

Good result - looks promising that this can be fetched straight to the Raspberry Pi - worth the humiliation of wearing your wife's snow shoes!

I did read somewhere that the DCF data was sent in a separate data packet once every minute. That may have been for the 30xx series of stations though.

Oh, and the Fine Offsets all seem to use binary coded decimal for date/time when storing in the memory, if they use the same in the radio packets it should be pretty easy to spot.

I did read somewhere that the DCF data was sent in a separate data packet once every minute. That may have been for the 30xx series of stations though.

That's probably the LUX/UV data from the solar module - still seems a bit inefficient to force the receiver on for two separate packets - I guess the solar stuff was shoehorned in.

The data format of transmitted data is quite a lot different from the format stored in memory on the receiver.

There's a lot of variety among the Fine Offset family of devices, even when they look the same on the outside. The only way to know anything for sure is to look, probe, and guess.

@avago Thank you for your moral support, my wife thinks I'm crazy ...

Lastly (and unrelated), I'm sure that, from the photo you posted, there's a DCF-77 antenna in your transmitter. If so, then some of the bytes you're receiving will certainly be date/time data.

Good result - looks promising that this can be fetched straight to the Raspberry Pi - worth the humiliation of wearing your wife's snow shoes!

Hmm. It certainly does look like the choke off a dcf77 tuned circuit. I don't have large enough cahoonies (is that how it's spelled?) to dismantle the wife's weather station (again) - it was a Christmas gift, and I just had to open up the transmitter to check it The frequency 868 was marked on the pcb. Ddint open up the receiver/display. I'd sworn I'd taken some photos, but cant find them.
IIRC 915Mhz is north america only. If the transceiver is bought as 915, you'll need to change a few caps to get it back to 868M, plus the setup. However, that info is based on the superbly accurate and well written datasheet

IIRC 915Mhz is north america only. If the transceiver is bought as 915, you'll need to change a few caps to get it back to 868M, plus the setup.

According to KarlS's profile, he's in BC, Canada, so 915MHz would be appropriate for his weather station's transmitter.

btw - those photos would be good to have, avago, should you happen across them (date-range search?). It was useful to have pics of my own and other people's PCBs, to find similarities and differences, when I was figuring out the Maplin version that I have.

Once again, thanks everyone for your help and suggestions.

I'm sure that, from the photo you posted, there's a DCF-77 antenna in your transmitter

DCF77 is transmitted from Frankfurt, Germany. North America/Canada is way out of reach for this signal. However, my console has a radio controlled clock (NIST, WWVB@60kHz). But why would they put the receiver for this signal into the TX instead of the console? Anyway, here is a good description of the time code format. I will have a look later.

The frequency 868 was marked on the pcb

So I had a good look at the photo I took of my pcb and found this:


Until now I thought this was the manufacturing date or something, but it might as well be the tx frequency. I changed my SPI params and the results so far look way more consistent. @avago: does the marking on your pcb look similar?

The AFC offset value that's returned in the status bytes will give you an indication of how far off the centre frequency your receiver has to go for the signal.

The 6 offset bits returned by the status command are either all 0 or all 1, so this won't help at the moment to determine the correct tx frequency.

However, I'd be more tempted to play around with the bitrate setting (Data Rate Command in datasheet). It could be that Fine Offset calculate it as a function of the transmit frequency. Try R = one of 17, 18, 20, 21. Maybe also try changing the clock-recovery setting (Data Filter command) to see if it makes a difference.

I haven't had time to try this yet, but it's next on my to-do list.

The 6 offset bits returned by the status command are either all 0 or all 1, so this won't help at the moment to determine the correct tx frequency.

All 1's could indicate that the deviation is more than -120kHz (e.g. -16 * 7.5kHz), so knocking around 240kHz off the centre frequency at a time (via Frequency Setting command) until you get an AFC offset of between -15 and 14, then you can home into the actual frequency.

btw, my guess about the time-signal receiver is that having it outdoors increases the chance of reception where the RF signal is weak. A side benefit is that each packet will likely contain its own accurate timestamp (useful to set the Pi's system time if no Internet is available).

Look forward to seeing the data...

IIRC 915Mhz is north america only. If the transceiver is bought as 915, you'll need to change a few caps to get it back to 868M, plus the setup.

According to KarlS's profile, he's in BC, Canada, so 915MHz would be appropriate for his weather station's transmitter.

btw - those photos would be good to have, avago, should you happen across them (date-range search?). It was useful to have pics of my own and other people's PCBs, to find similarities and differences, when I was figuring out the Maplin version that I have.

Got my posts mixed up. Thought the guy was in Scotland...
BTW, getting some success with getting the 0x0000 command working to read the FIFO. Instead of using a 16 bit read and changing on the fly to 8 bit read, I'm just doing 3 x 8 bytes at 5MHz. I say limited as I'm now getting more bit errors, so it sounds very much like a SPI issue.
I did a date search for the photos, even checked the missus phone, just in case I used hers!

I'm just doing 3 x 8 bytes at 5MHz. I say limited as I'm now getting more bit errors, so it sounds very much like a SPI issue.

Do the bit errors also happen in the first two bytes? I ask because it crossed my mind that the 2.5MHz limit, stated in the datasheet, is because of hardware limitations of the FIFO shift-register on the chip. So, RAM can be reliably accessed at high-speed, but the FIFO register can't.