EBRC Weather Station Revisited

EBRC Weather Station, Today and Tomorrow

I’m sure everyone is familiar with our weather station on the website shown below including the battery voltage status from the field. 

But you may not know about how it’s put together and what makes it work.  This article is intended to provide that background information, discuss the recent radio replacement and offer an improvement to some of the consumption concerns. 

As you know, we recently had a failure of the weather station.  The problem was traced to the field radio which was replaced.  While we have little data on the old radio, I am sure this new one consumes more power.  So, we need to reassess the impact to our battery and solar charging setup.  

Below is a block diagram of our system.  The stuff on the left is at the field and the stuff on the right is at Chris’s house. 

Current EBRC Weather Station Setup

The following is the stuff at the field.

EBRC Field Equipment

The old radio had a transmit power of 20mw although we don’t have a sense of how much was consumed from the battery to produce this tx power.  This radio had 3 channels and you pick a clear one to use for the link and cross your fingers. 

The new radio has a 1 watt tx capability but we’re only using the 100mw setting now.  The next lesser setting is 10mw.  We don’t feel comfortable going to 10mw because the previously used 20mw provided marginal link robustness.  We can explore as fine tuning continues. 

This new radio uses frequency hopping technology (FHSS) like our models;  since it’s a 1 watt radio it uses 50 channels and you can change the hop sequence if you like. 

Data collected from RGVM. 

Here is some data from the current RGVM (Rain Gauge Volt Meter).  As you can see, this plot gives us insights into the state of the battery all day, every day.  You can see from the plots the following voltage events.  This plot shows about 5 days.

a.          when charging starts (fast increase)

b.          when charging stops (fast decrease)

c.           Charge controller induced noise(top)

d.          Overnight battery sag (slow decrease)

 

About 5 Day Plot of Battery Voltage

The plot title refers to a hardware filtering change I made on the board to filter the noise generated from the charge controller (fuzziness up top). 

It is interesting that, on some days, there is voltage sag sometimes but not others;  not sure if this is temperature related or a measurement artifact.  The battery holds up well overnight only discharging to about 12.6v; when the battery sags to 11v, I pull the battery and swap it out to prevent over discharge which can occur in the winter time. 

Following is a 1 day section with more detail.  You can see that there is enough solar panel output to start charging about 7am and the charge continues to about 8:30pm on this August day.

 

Single Day Battery Voltage

The next level

To get a sense of what was happening with our weather station system on the RS232 lines, I dug out an old piece of test equipment I designed and built in 2000, an RS232 sniffer.  It uses a hardware scheme to sniff what traffic is on any RS232 line assuming it is half duplex (data flowing only one way at a time, never simultaneously).  From this I discovered the actual packets sent to the radio which is a 5 sec packet and 10 sec packet.  Samples of both packets are below.  The 232 comms documentation is sparse so it was easier to measure it to see what we had. 

Once I had the packets, I searched and found a protocol document on the web that described the byte level details.  I’ve organized the packets in groups according to the protocol document. 

short packet(CF group, 27 bytes, every 5 sec, included in long packet below)

3f 50 40 28 33 40 29 3f 30 28 20 04 06 68 05 3f

19 06 34 18 31 07 21 19 50 04 7b

 

long packet(every 10 sec, includes CF group)

(8F group, 35 bytes, time, humidity)

3f 58 15 23 08 08 00 00 47 72 50 19 03 58 61 72

40 72 3f 10 19 67 00 18 01 08 01 52 30 3f 3f 10

00 00 23

 

(9F group, 34 bytes, temp indoor and outdoor with alarms)

3f 12 02 40 34 07 09 77 10 41 17 01 28 12 32 70

20 02 38 24 02 24 3f 09 28 17 01 08 14 40 38 00

00 3f

 

(AF group, 31 bytes, barometer and indoor/outdoor dew point)

3f 3f 09 10 3f 00 24 09 15 39 03 20 07 40 45 31

71 00 00 11 00 00 01 01 50 31 3f 3f 0d 00 61

 

(BF group, 14 bytes, rain)

3f 48 03 3f 3f 3f 3f 00 00 01 31 3f 23 25

 

(CF group, 27 bytes, wind and wind chill)

3f 35 3f 25 37 10 31 3f 30 28 20 04 06 68 05 3f

20 06 34 18 31 07 21 19 50 04 3f

 

In the old RGVM, we faked out the weather station rain gauge input to send the battery voltage information.  The weather station put this information into the appropriate packet (BF Group) which traveled to the internet. 

On the Improvement Side.

OK, we’re using more power in the form of the new radio, do we need to upgrade the battery and solar charger?  Not sure yet, investigating. 

Is there a way to optimize the power we have available now?  Yes there is!

Currently, the weather station puts out a big packet every 10 seconds (everything including wind, 141 bytes) and a smaller one every 5 seconds (wind info only, 27 bytes).  While all the info is received at the laptop at the other end of the link, we only upload information to weather underground every 5 minutes.  This slower update to the web is for a couple of reasons

a.        Since we are using Chris’s internet pipe for free, we want to consume very little of it.  I think the current 5 minute interval is quite adequate for our needs. 

b.      The displayed that you see on weather underground is actually built inside the virtual weather station (laptop) and sent along.  This is much more information than just the numbers, it is the full graphical picture.  So, it’s a big chunk of data. 

Looking at this from the standpoint of battery conservation at the field, we send data every 5-10 seconds but only update the web every 5 minutes.  So, we send a lot of data from the field, all of which consumes battery power,  but most of this data is never used.   We can be smarter on battery usage if we just send our weather data less often.  

Unfortunately, we cannot control how often the weather station sends data.  It’s fixed at 5/10 second intervals.  And everything from the weather station is broadcast over the radio.  This is one issue.

Our new radio has a power down capability if we utilize flow control in how we send data over the RS232 link.  Unfortunately, the weather station doesn’t have flow control capability.  Even if it did, we’re sending much more data than is necessary.  This is the second issue, lack of flow control.

A solution. 

Since the weather station is connected directly to the radio at this point, we can’t do much with the current setup.

But if we put something between the weather station and the radio, then we can send the radio less data and thus consume less battery power.    We can also reduce battery consumption by turning off the radio between packets.  Double win!

I envision the following would solve both issues.  We can also do the voltage monitoring (what RGVM is doing now) and as well add a current monitor as an enhancement.  Let’s call this box an RS232 Interposer since it takes in all the weather station RS232 data but only sends along some of it. 

Proposed Weather Station Improvement

Hopefully we can save enough power that the current battery and charging setup will remain adequate for our needs. 

While we hope the current battery and charging system are adequate, we really don’t know at this point.  The only way we will find out is to ride through a winter season and see how many times we need to replace the battery.  We can optimize our consumption as much as possible and monitor along the way to more fully understand our options. 

With monitored data, if we need to upgrade the battery system, we will have a good idea of how much we need.  The RS232 Interposer can provide this monitoring with measured current consumption. 

Voltage alone tells us a lot as described earlier, but it doesn’t tell us about the current that is consumed by the gear or the charge current into the battery from the solar panel.  The voltage only tells us how well the battery can sustain the voltage at the given load current without actually knowing what that load is.  An improvement could be to monitor the consumed (load) current. 

In the RGVM, the battery voltage was encoded and put through the weather station.  There were some limitations with this method, such as the granularity of the measurement (0.04v).  Using the RS232 Interposer , we can put the information directly into the packet and not suffer from this granularity limitation.  Another improvement!

To know where to put the data in the packets, we need to understand how the packets are constructed;  this information is revealed by the protocol document.  Since we’re using the rain packet position for our information, we can just pass the other most recent packets through (latest version) and change the rain packet only.

Hardware and space considerations

Another consideration is the space we have to mount this board.  Board size estimates below.

 

Length

width

RGVM

3”

2”

232 interposer with RF101

4.5”

3.25”

232 interposer with BF506F

5”

4.5”

Cavity in box

xx

yy

Power estimates

Following are some power estimates the RS232 interposer which includes our current radio.  I’m considering two different controllers for the next model;   A BF506F or an ADuCRF101 (top current contender). 

One interesting point is that the radio receive function is the highest consumer at 1.3W at least according to the datasheets.  So this is the top contender for reduction.  We can use flow control to the radio to put the radio to sleep between transmissions. Interestingly enough, we aren’t receiving anything at the field. 

We really only ever need the radio at the field to transmit, and the radio in Chris’s attic only ever needs to receive.  Since the one in Chris’s attic is power by 120VAC it’s not as much of an issue as the one at the field consuming our precious battery. 

A spreadsheet on the next page is a reasonable starting point as to where we expect to be on the consumption side at the field.  As the project proceeds, I’ll update it to maintain a good view of where we are.  All the numbers here are from the datasheets and not measured.

 

So, that’s pretty much my current project, building the RS232 Interposer.  I think there is some value for the club and it should help us to keep getting the weather information reliably.

Happy flying.


EBRC weather station consumption comparison

8/22/2013 tmw

BF506F

ADuCRF101

speed (Mhz)

I(ma)

V

Watts (mw)

speed (Mhz)

I(ma)

V

mw

1

BF506F

Vddint

200

51

1.3

66.3

Vddint

300

75

1.3

Iddflash

20

3.3

66.0

Iddext

3.3

1

RF101  static

16

2

3.3

6.6

   dynamic

210uA/Mhz  16

3.36

3.3

11.1

  RF in rx

13

3.3

42.9

  RF in tx

9-32ma

9

3.3

29.7

1

AD8206

difference amp

7.7

5

38.5

7.7

5

38.5

2

ADM3202

12

3.3

79.2

12

3.3

79.2

totals with radio

250.0

208.0

totals without RF101 radio

154.0

1

main radio   tx(100mw) 9600

150 bytes, bit time=104us

250

3.9

12

46.8

250

3.75

12

45.0

                          rx

110

12

1320.0

110

12

1320.0

                          rx with idle

25

12

weather station

12

full BF506F ezkit

5

5

full RF101 board

5

5

 

PrintEmail