Fine Offset WH1081 (Maplin N96GY) sensors working on Pi


186 posts   Page 1 of 8   1, 2, 3, 4, 5 ... 8
by ksangeelee » Fri Aug 17, 2012 9:39 am
I've managed to get the outdoor sensors of my Maplin N96GY Weather Station (or N96FY, basically a Fine Offset WH1081) reading on my Raspberry Pi using an RFM01 (Hope RF) receiver module, and have written up the results here: -

http://www.susa.net/wordpress/2012/08/r ... nd-rfm12b/

The software I've written dumps out the 10 hex-bytes received every 48 seconds, and I've described the packet format for conversion into meaningful values (I'll probably add decoding to the software next). The outdoor sensors send temperature, humidity, wind-direction, wind-speed, gust-speed, and rainfall.

For barometric pressure, I'm also going to add an I2C sensor to the Pi, since the weather station's barometer is part of the LCD display rather than on the transmitter mast.

Cost of bits is about £5. A barometer chip is an extra £9 I think. The range is significantly better than the standard head unit.
Posts: 193
Joined: Sun Dec 25, 2011 5:25 pm
Location: Edinburgh, UK
by ksangeelee » Sat Sep 29, 2012 2:03 pm
Since a few people have assembled one of these, I'll use this thread to notify of any significant updates, so you can use the forum's 'Watch' feature if you'd like to be notified.

Since my original post, the code has changed a bit, and now supports the BMP085 barometric pressure I2C module. The RF data format information has had some unknowns/mistakes clarified. Support for the RFM12B has fallen by the wayside, in favour of the RFM01 (much better results, cheaper and easier to buy).

The article and download (link) have been updated.
Posts: 193
Joined: Sun Dec 25, 2011 5:25 pm
Location: Edinburgh, UK
by dickydodds » Thu Jan 03, 2013 8:59 pm
Hi all.

I have wired this up and am using the version 0.3 software on a rev 2 board. I changed the code to use GPIO27 as per my request for info to Kevin who was very quick to help me.

However, I cant get any data printed so am looking to see what others (you guys) have done to get the data received and decoded. Been plugging this for 2 days now (and I haven't moved the transmitter to the pi which I know might help...)

I have the maplin N96GY module (says 433.9Mhz on the back) and the RFM01 module
I am using LNA_0,RSSI_97 idx 4 and a bandwidth of 67 as follows:-

Code: Select all
        uint16_t cmd_config     = CMD_CONFIG|BAND_433|LOAD_CAP_12C0|BW_67;
        uint16_t cmd_rcon       = (CMD_RCON|RX_EN|VDI_DRSSI|LNA_0|RSSI_97);


my RSSI output looks like this (snippit):-

Code: Select all
 LNA_0,RSSI_85 idx 2     0.00    0.00    0.00    0.00    0.00    0.00
  LNA_0,RSSI_91 idx 3     0.00    0.00    0.00    0.00    0.00    0.00
  LNA_0,RSSI_97 idx 4     0.00<  40.43  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    0.00    0.00    0.00
  LNA_6,RSSI_91 idx 9     0.00    0.00    0.00    0.00    0.00    0.00
  LNA_6,RSSI_97 idx 10    0.00    0.00    0.00    4.17    1.04   47.83
 LNA_6,RSSI_103 idx 11   94.74  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


I know the GPIO is working because if I disconnect it all the RSSI values drop to zero '0'
I also know I am jumping as far as the realtime schedular as I see my printf statement telling me so but I never enter a pin transitioning part of the code - see below :-

Code: Select all
        scheduler_realtime();
printf("Switched over to realtime schedular\n");
        do {

                // Read the GPIO pin for clocked DATA value
                status = ((*(gpio.addr + 13)) >> 27) & 1;
                rssi = status;
                rssitime = TIMER_ARM_COUNT;
                // Check if the pin transitioned
                if(rssi != oldrssi) {
                        // If falling edge (1 -> 0), then store bit pulse duration
                                  printf("Pin Transitioned\n");
                                if(rssi == 0) {


Has anyone else hit this issue and if so, how did you manage to fix it?

Btw, also noticed moving the orientation of the rfm01 / aerial make the 'sweet spot' change - how likely is that to be an issue with lost packets? Also, I am not a C programmer!

thanks,

Dicky
Posts: 25
Joined: Sun Oct 14, 2012 10:40 am
by ksangeelee » Fri Jan 04, 2013 1:41 am
I'd really recommend you bring the transmitter (leave the sensors) beside the Pi if you want to debug this - alternatively, if you're sure you're in good receiving range, then at least keep the LCD unit beside you, allowing you to see when it receives data (and hence when your code should be receiving data).

On your question of board orientation, the RFM01 (and RFM12b) receiver is sensitive to noise radiating from the Pi, and from switching PSUs - though only in OOK mode (from experience, it's very resilient when using FSK).

To reduce noise sensitivity, I used 50 Ohm coax to take the antenna further from the Pi. I also (just this morning) wrapped aluminium foil, placed in a thin freezer bag for insulation, around the RFM01 to shield it from the noisy PSU I cobbled together from a low-voltage lighting transformer. It seems to have made a noticeable difference.

The code you mention enters realtime scheduling mode and loops constantly until it gets enough bits, containing a valid packet. It then starts looking again every 48 seconds (approx). If it doesn't get past this loop, then it's not finding a valid packet.

I'll mention, just in case, that I can't imagine the timing working reliably if X is running. Stick to the console if you've been running X.

Lastly, a tip if you want to see if bits are coming through the data pin in response to RF - lots of car key-fobs, among other things, operate on 433MHz and can be used to generate bit-streams that the receiver will pick up. This will likely show up as dots appearing on screen (signifying short-packets seen by the software).
Posts: 193
Joined: Sun Dec 25, 2011 5:25 pm
Location: Edinburgh, UK
by dickydodds » Fri Jan 04, 2013 8:49 pm
Using the keyfob I now understand what monitoring the RSSI number is all about now - it tells you what signals are being received by the rfm01 and what strength! Its really cool to see whats going on on that frequency as theres loads of stuff!! I can see around 6 different signals - most really low like 1 - 5.
I can see that the rssi value sits at 0.00 then, every 12.5 seconds a signal comes through which is generally 31.70. Now I know its not mine as I turned off my second remote temperature sensor and my KW hour meter (BTW, there's an rmf01 xmitter and reciever in the EON energy meter if someone needs one quick).

I can also see my Maplin sensors coming through approx every 48 seconds - I see a blip of 48.0 - 50.0. This looks like a nice strong signal to me!

What I don't see is any dots or any of my printf statements dictating a pin transition.

I don't have X running and I changed the priority as per your instructions.

So, the next step is to bring down the transmitter and try it close to the unit - I will know then once and for all!
Hopefully saturday evening as I am busy during the day!

Dicky
Posts: 25
Joined: Sun Oct 14, 2012 10:40 am
by ksangeelee » Fri Jan 04, 2013 9:07 pm
dickydodds wrote:So, the next step is to bring down the transmitter and try it close to the unit - I will know then once and for all!


When the transmitter is close by, you can drop the amplification and RSSI threshold right down to reduce sensitivity - this will eliminate most sources of interference from what appears out of the RFM01's DATA pin.

It will also be more forgiving of dodgy antenna wiring (I'm sure I got reception without an antenna even connected when the transmitter was close by).
Posts: 193
Joined: Sun Dec 25, 2011 5:25 pm
Location: Edinburgh, UK
by dickydodds » Fri Jan 04, 2013 9:43 pm
Thanks for the tip - proof is in the pudding tomorrow night!

BTW, are you running yours on a rev 2 board?

Dicky
Posts: 25
Joined: Sun Oct 14, 2012 10:40 am
by ksangeelee » Fri Jan 04, 2013 9:52 pm
dickydodds wrote: proof is in the pudding tomorrow night!

BTW, are you running yours on a rev 2 board?


I've only ever run it on a rev 1 board, though I do have a rev 2 if I ever make time to update the software properly (I'm currently adding config-file support and command line parameters, which is more useful to me at the moment).
Posts: 193
Joined: Sun Dec 25, 2011 5:25 pm
Location: Edinburgh, UK
by dickydodds » Sat Jan 05, 2013 5:31 pm
Right - getting somewhere now! The xmitter is now inches away from the receiver and I still got nothing....so...

in the code I left this line untouched cos I have no idea what it does... -
Code: Select all
 // Init GPIO21 (on pin 13) as input (DATA), GPIO22 (pin 15) as output (nRES)
        *(gpio.addr + 2) = (*(gpio.addr + 2) & 0xfffffe07)|(0x001 << 6);


and changed this input pin from GOIO 27 to GPIO 17:-

Code: Select all
// Read the GPIO pin for clocked DATA value
                status = ((*(gpio.addr + 13)) >> 17) & 1;


and used gordons app to set GPIO 17 as an input as follows:-

Code: Select all
./gpio -g mode 17 in


and now I am getting somewhere as I get short packets coming in as follows:-


Code: Select all
RSSI Duty 0.00
Data bits = 83   (offset 0) (40 short) No packet signature found
Pulse stats: Hi: 974 - 980   Lo: 1001 - 4682  (83 point)
.....Pulse stats: Hi: 973 - 990   Lo: 1003 - 2117  (43 point)
Data bits = 86   (offset 0) (87 short) No packet signature found
Pulse stats: Hi: 984 - 999   Lo: 1001 - 3572  (86 point)
Data bits = 88   (offset 0) (151 short) No packet signature found
Pulse stats: Hi: 973 - 995   Lo: 1011 - 2292  (88 point)


so now I can play around a bit. I have no idea why the line wont work as you suggested - but maybe that can be sorted out in Version 0.4.

Thanks very much for your help so far. I am now going to have a play around and hopefully get some results coming through!

Dicky
Posts: 25
Joined: Sun Oct 14, 2012 10:40 am
by dickydodds » Sat Jan 05, 2013 6:50 pm
OK, were cooking now - but I had to stop the code checking for the signature and just accept any 88 byte packets. Luckily, you only decode packets if the CRC is ok. So I changed 1 line as follows:-

Code: Select all
//                              if(count == 88 && sig_matched) { // then probably a data packet
                                 if(count == 88 ) { // then probably a data packet


so now it doesn't check the signature which I read can change in your original article.

Now, I cant put it back up till tomorrow as its too dark to see lol!!!

Another thing I noticed, is that I am using a bandwidth / RSSI setting which is NOT near a noise boundary as they didn't work for me so trial and error produced this which works at present -

LNA_6,RSSI_85 idx 8 0.00 0.00 0.00 0.00 0.00 0.00
LNA_6,RSSI_91 idx 9 0.00< 0.00 0.00 0.00 0.00 0.00
LNA_6,RSSI_97 idx 10 0.00 0.00 25.00 96.84 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


Hope this helps you and others!

Cheers,

Dicky
Posts: 25
Joined: Sun Oct 14, 2012 10:40 am
by ksangeelee » Sat Jan 05, 2013 7:40 pm
dickydodds wrote:OK, were cooking now - but I had to stop the code checking for the signature and just accept any 88 byte packets. Luckily, you only decode packets if the CRC is ok.


Good stuff, that's interesting about the packet signature code not working - can you post or email the hex-dump of bytes that get output for one of your data packets please?

Someone else discovered that the station-id changes with power-cycles of the transmitter (e.g. after changing batteries), and I'd modified the code to try to take this into account - works for me (and at least one other person), but I may have missed something.
Posts: 193
Joined: Sun Dec 25, 2011 5:25 pm
Location: Edinburgh, UK
by ksangeelee » Sat Jan 05, 2013 8:20 pm
dickydodds wrote:in the code I left this line untouched cos I have no idea what it does... -
Code: Select all
 // Init GPIO21 (on pin 13) as input (DATA), GPIO22 (pin 15) as output (nRES)
        *(gpio.addr + 2) = (*(gpio.addr + 2) & 0xfffffe07)|(0x001 << 6);



*(gpio.addr + 2) is the hardware register GPFSEL2, which is used to specify the function of GPIO20 through GPIO29 (e.g. input, output, alternate function...,). The value 0xfffffe07 is a mask used to clear bits 3-8 of this register (GPIO21 and GPIO22). Convert the hex to binary and it should become more apparent.

If you're not using an output (LED or whatever), then only GPIO27 would be needed on your rev-2 board, so it would be enough to say: -
Code: Select all
*(gpio.addr + 2) = (*(gpio.addr + 2) & 0xff1fffff);

which would simply force bits 23-21 of GPFSEL2 to zero (e.g. make it an input pin).

For GPIO17, you'd need to modify GPFSEL1 (gpio.addr + 1), since that's where the function-select bits of that GPIO pin are. Coincidentally, the relevant bits are 23-21, so the mask would remain the same.

As I understand it, all GPIO pins other than the UART default to inputs, so unless some other program has changed the pin configuration, it should work without specifically configuring it (though I recommend you do).
Posts: 193
Joined: Sun Dec 25, 2011 5:25 pm
Location: Edinburgh, UK
by aideen » Sat Jan 05, 2013 8:52 pm
Wahey! That works :-) Many thanks for this great project Kevin.

I'm using an RFM01 mounted on an Eve Alpha board to talk to a Maplin N96GY.

Just got things talking earlier today using a Pi Rev-1 and was now trying with a Rev-2 ... but hadn't got my head around GPFSELn yet.

It's working very well with no noise issues (BW_67, LNA_14, RSSI_91).
:
Listening for transmission
Data bits = 88 (offset 8) (9 short) Packet signature found
Frequency deviation -1.0KHz (-1)
a1 c1 db 57 00 00 01 1d 08 31 crc ok (gap 48s)
Pulse stats: Hi: 565 - 637 Lo: 1571 - 1670 (88 point)
Threshold now 1104
Station Id: 0A1C
Temperature: 7.5C, Humidity: 87%
Wind speed: 0.00 m/s, Gust Speed 0.00 m/s, S
Wind speed: 0.0 mph, Gust Speed 0.0 mph, S
Total rain: 85.5 mm
Listening for transmission
Data bits = 88 (offset 8) (9 short) Packet signature found
Frequency deviation 0.0KHz (0)
a1 c1 db 58 00 01 01 1d 06 fb crc ok (gap 48s)
Pulse stats: Hi: 592 - 706 Lo: 1590 - 1680 (88 point)
Threshold now 1148
Station Id: 0A1C
Temperature: 7.5C, Humidity: 88%
Wind speed: 0.00 m/s, Gust Speed 0.34 m/s, SE
Wind speed: 0.0 mph, Gust Speed 0.8 mph, SE
Total rain: 85.5 mm
:
Will post a link to a picture of the Eve setup in due course.

Thanks again!

Aideen
Posts: 17
Joined: Fri Jun 15, 2012 11:43 pm
Location: Cambridge, UK
by ksangeelee » Sat Jan 05, 2013 9:20 pm
Good stuff Aideen, I'd be interested to know how your setup performs on a board designed specifically for RF modules, and how sensitive it is to noise from Pi/PSU/etc.
Posts: 193
Joined: Sun Dec 25, 2011 5:25 pm
Location: Edinburgh, UK
by dickydodds » Sat Jan 05, 2013 9:47 pm
Thanks for the info in your posts - this is a new vanilla pi with nothing else running on it.

Here's a sample output of bytes -

Data bits = 88 (offset 8) (0 short) Packet signature found
Frequency deviation 7.0KHz (7)
a1 31 d1 59 00 00 09 dd 02 68 crc ok (gap 5s)
Pulse stats: Hi: 314 - 456 Lo: 1396 - 1503 (88 point)
Threshold now 926
Station Id: 0A13
Temperature: 6.5C, Humidity: 89%
Wind speed: 0.00 m/s, Gust Speed 0.00 m/s, NE
Wind speed: 0.0 mph, Gust Speed 0.0 mph, NE
Total rain: 757.5 mm

I take it we need to start recording and subtracting the Total Rain value from the recording to find the rainfall as mine, for instance, is big a 757.5mm?

Also, 1 consequence of removing the signature part is a crc of 0 when all bytes are zero too lol!

Frequency deviation 6.0KHz (6)
00 00 00 00 00 00 00 00 00 00 crc ok (gap 48s)
Pulse stats: Hi: 999999 - 0 Lo: 987 - 2131 (88 point)

From what you describe it sounds like the Rev 2 board isn't quite working the same as a Rev 1 board or I wouldn't be having all these issues!

Thanks again for your help Kevin - you have put a lot of work into this!

Dicky
Posts: 25
Joined: Sun Oct 14, 2012 10:40 am
by dickydodds » Sat Jan 05, 2013 9:54 pm
BTW, just for info I just noticed the short bits has steadily incremented upwards from zero too to 110 in approx 40 minutes...



Data bits = 88 (offset 8) (0 short) Packet signature found
Data bits = 88 (offset 8) (39 short) Packet signature found
Data bits = 88 (offset 8) (48 short) Packet signature found
Data bits = 88 (offset 8) (52 short) Packet signature found
Data bits = 88 (offset 8) (93 short) Packet signature found
Data bits = 88 (offset 8) (101 short) Packet signature found
Data bits = 88 (offset 8) (105 short) Packet signature found
Data bits = 88 (offset 8) (110 short) Packet signature found
Posts: 25
Joined: Sun Oct 14, 2012 10:40 am
by ksangeelee » Sat Jan 05, 2013 10:03 pm
dickydodds wrote:BTW, just for info I just noticed the short bits has steadily incremented upwards from zero too to 110 in approx 40 minutes...

Data bits = 88 (offset 8) (0 short) Packet signature found
...
Data bits = 88 (offset 8) (110 short) Packet signature found


That's generally ok - it's just the module picking up RF signals that are too short to be data-packets, but worth counting, because they give you an indication of noise that might interfere with the signal you're looking for.

Your settings may be a little too sensitive, but then again they may be as good as it gets and it's just that there are other things transmitting on a similar frequency.
Posts: 193
Joined: Sun Dec 25, 2011 5:25 pm
Location: Edinburgh, UK
by dickydodds » Sun Jan 06, 2013 9:33 pm
FYI - I have had to disable the strobe_afc routine as that "seems" to be causing the packet of data to stop being decoded. By disabling the call to it I now have (so far anyway) a good decoding of the signal, however, the short bits message is still increasing at present so it may stop later.

Before disabling it, the packets would fail to be decoded within 5 or 10 minutes no matter what bandwidth and rssi and lna settings I was using, however, this current attempt has been going about an hour and a half so far without the AFC control - my longest ever!.

My current settings are LNA_0 |RSSI_85|BW_134 so shouldn't be overly sensitive I guess.

The reason I did this is because noticed the frequency deviation would increase (-1.0, -2.0 etc) and then eventually stop decoding. Its certainly better and lasted the longest so far without.

Don't know if anyone else has seen this?

Dicky
Posts: 25
Joined: Sun Oct 14, 2012 10:40 am
by ksangeelee » Mon Jan 07, 2013 1:00 am
dickydodds wrote:My current settings are LNA_0 |RSSI_85|BW_134 so shouldn't be overly sensitive I guess.


The LNA offset number represents a negative dB offset from highest gain, so LNA_0 is actually the highest amplification (and hence most likely to pick up noise). Check the RFM01 datasheet for a bit more detail.

Strobing the AFC was an attempt to manually set the auto-frequency control registers on a successful read, the intention being to follow environmental drift. I think it makes sense to use it with a clear signal, but perhaps it's causing problems because yours is marginal (and that could be too strong or too weak).

My guess is that, even with strobing of AFC registers disabled, you'll run into issues eventually (due to significant changes in temperature, humidity/rain, physical obstacles, etc.) but I'd be interested to know if this turns out not to be the case.
Posts: 193
Joined: Sun Dec 25, 2011 5:25 pm
Location: Edinburgh, UK
by dickydodds » Mon Jan 07, 2013 7:50 am
Hi Kevin,

Clearly I was wrong about the sensitivity! Thanks for the explanation and I can fully understand what your trying to achieve with it and, yes, it would be a good thing to have.

Strangely enough, its worked all night (I sent the output to a file) despite the shorts ever increasing from 2 to 544 at the moment - I really expected it to fail....

Listening for transmission
Data bits = 88 (offset 8) (544 short) Packet signature found
a1 31 e7 59 03 05 09 dd 0a b4 crc ok (gap 48s)

I will leave it running all day and see what happens.

I hope these observations are helping rather than hindering you and helping giving insight to whats happening in your program.

Dicky
Posts: 25
Joined: Sun Oct 14, 2012 10:40 am
by ksangeelee » Mon Jan 07, 2013 9:24 am
dickydodds wrote:I hope these observations are helping rather than hindering you and helping giving insight to whats happening in your program.

Always helpful, thanks. I only have one environment to test for myself, so I have no idea how it performs in other situations. e.g. up till now, I thought AFC strobing had no clear-cut effect - so turns out it sometimes makes a noticeable difference.

I'm adding a config file and command-line parameters, so this is one worth adding as a flag.
Posts: 193
Joined: Sun Dec 25, 2011 5:25 pm
Location: Edinburgh, UK
by dickydodds » Mon Jan 07, 2013 7:57 pm
Glad to be of service then!

So, I have run this all day and all night in the background and sent the output to a file and we are still going strong - unbelievable! (this is the only thing I am running on the pi though).

Shorts are ever increasing.

Listening for transmission
Data bits = 88 (offset 8) (1368 short) Packet signature found
a1 31 f6 53 02 05 09 dd 0a 75 crc ok (gap 48s)
Pulse stats: Hi: 452 - 557 Lo: 1459 - 1578 (88 point)

My file is 3.5meg long and a quick glance through ti shows what must be less than 5 bad packets received still on the same settings - the unit is sitting near the window of the sitting room approx 15 metres or so away from the transmitter.

Config file sounds great - if you have the time, add an option to push the raw data to a file such that there is only ever one line of data which gets overwritten - we can then parse that file from python or whatever. I already started hacking your code with my limited knowledge to get an output as follows -

10.2C, 84%, 0.8, 3.0, S, 757.5

I want to put this data into an rrd database and produce my graphs from there - hence learning Python now!

Feel free to use me as a guinea pig for future code versions :D
Posts: 25
Joined: Sun Oct 14, 2012 10:40 am
by ksangeelee » Mon Jan 07, 2013 8:13 pm
dickydodds wrote:...add an option to push the raw data to a file such that there is only ever one line of data which gets overwritten - we can then parse that file from python or whatever. I already started hacking your code with my limited knowledge to get an output as follows -

10.2C, 84%, 0.8, 3.0, S, 757.5

I want to put this data into an rrd database and produce my graphs from there - hence learning Python now!


You could write one-line data to a file in /tmp, so it's in RAM (saving your SD card from wear). It's straightforward - just C functions fopen(), fprintf(), and fclose(). Then perhaps launch some post-processing in the 48-second interval using a system() call.

Ken McCullagh (kenmc) has extended the software to write to a SQLite DB, and has it graphing with pywws. He had a git repository (announced in a forum, I think), but I'm not sure if it's up to date with all his additions.
Posts: 193
Joined: Sun Dec 25, 2011 5:25 pm
Location: Edinburgh, UK
by dickydodds » Mon Jan 07, 2013 9:28 pm
Thanks Kevin, I will have a go at creating that file and using /tmp is a great tip too!
Dicky
Posts: 25
Joined: Sun Oct 14, 2012 10:40 am
by kenmc » Tue Jan 08, 2013 10:17 am
ksangeelee wrote:
dickydodds wrote:...add an option to push the raw data to a file such that there is only ever one line of data which gets overwritten - we can then parse that file from python or whatever. I already started hacking your code with my limited knowledge to get an output as follows -

10.2C, 84%, 0.8, 3.0, S, 757.5

I want to put this data into an rrd database and produce my graphs from there - hence learning Python now!


You could write one-line data to a file in /tmp, so it's in RAM (saving your SD card from wear). It's straightforward - just C functions fopen(), fprintf(), and fclose(). Then perhaps launch some post-processing in the 48-second interval using a system() call.

Ken McCullagh (kenmc) has extended the software to write to a SQLite DB, and has it graphing with pywws. He had a git repository (announced in a forum, I think), but I'm not sure if it's up to date with all his additions.


Hi,
yeah the github is way behind what I'm running. Must start over with it, to give the sqlite stuff and writing into pywws format. Didn't realise having a baby would reduce my computer time so much!!! I thought she'd just sleep most of the time; and she does, but then I've to catch up on all the stuff my good wife didn't get done while playing with the little one.

Anyway, yes, I have it interfacing with sqlite, also writing to the pywws format stuff. Then PYWWS comes along and does its' magic on the raw data as if it had gone and interfaced with the head unit.
Will try get the code updated asap...

I've also got it sending me a copy of the database every couple of hours in an email (mainly so I can play with "current" data in terms of parsing python stuff, graphing etc)
A crontab looks at the battery state from the database and emails me when the battery is low
Another crontab also looks to see if there's been no data received and restarts the program in case it's gotten into a loop.
http://goatstownweather.hostoi.com
Posts: 51
Joined: Fri May 04, 2012 8:02 am
Location: Dublin, Ireland