Gina
-
Posts
45,326 -
Joined
-
Last visited
-
Days Won
120
Content Type
Profiles
Forums
Gallery
Events
Blogs
Posts posted by Gina
-
-
As I add stuff to my observatory I continue to add 13.8v to 5v buck converters. I could be adding 3 more with the weather sensors. This is making me wonder whether I should add a 5v power bus to my observatory power distribution system.
-
Must make sure brain is fully engaged and working before engaging fingers to keyboard!!
-
Yep - I got confused!
-
Sorry - me getting confused!!
-
I've uploaded the sketch to the two new ESP32s I've just bought so this gives me the framework to add my own code and remove what I don't want. Really it just a test that the Upload works on the two new modules.
-
String SendHTML(float temperature,float humidity,float pressure,float altitude){ String ptr = "<!DOCTYPE html>"; ptr +="<html>"; ptr +="<head>"; <------------------------------------------------- WRONG!! ptr +="<title>ESP32 Weather Station</title>"; ptr +="<meta name='viewport' content='width=device-width, initial-scale=1.0'>"; ptr +="<link href='https://fonts.googleapis.com/css?family=Open+Sans:300,400,600' rel='stylesheet'>"; ptr +="<style>";
-
Filters only make invisible objects visible with long exposure imaging.
-
1 hour ago, JamesF said:
In that case if we assumed pin 0 is N, pin 1 is NE, pin 2 is E and so on around the compass points, I would probably do something similar to this:
pinValues = 0; for ( p = 0; p < 8 ; p++ ) { if ( pin p is on ) { pinValues |= ( 1 << p ); } } windDirection = UNDEFINED; switch ( pinValues ) { case 0x01 : windDirection = NORTH; break; case 0x03 : windDirection = NNE; break; case 0x02 : windDirection = NE; break; case 0x06 : windDirection = ENE; break; case 0x04 : windDirection = E; break; // ...etc }
James
I may be wrong but I don't think your for loop gives the right results. I worked out that the pins needed special numbering viz. 1 2 4 5 6 7 8 9. Note that 3 had to be left out as we get that with NNE from N + NE (1+2).
-
No, I hadn'r come across Consensus Averaging before either - it's very clever and makes use of the waggling of the vane to get a better resolution out of the 16 compass points. My earlier weather stations used magnetic damping to reduce the waggling. Then to get an average I would use 16 bins to collect points for each direction and use the one with the most counts as the true direction. Consensus Averaging takes this much further.
-
Ah yes, that's a simpler method - thank you.
Actually, since I shall go on to do Consensus Averaging I'll use integer values 0-15.
-
Yes, that was one of the alternatives I had in mind but the 8+1 wire digital connection doesn't need any resistors. Otherwise not a lot to choose between them - no resistors v more wires.
-
13 minutes ago, JamesF said:
Do you have to read the pins individually, or can you read them all in one go?
James
I think they have to be read individually.
-
Thinking online... Let's look at how a table may be formed. We have a "1" for N, NE, E, SE, S, SW, W, NW. If we assign a value of 1 for N and 2 for NE we have 1, 2 or 3. So the value for E has to be 4. With E on we can have that alone or with NE or SE. NE has a value of 2 so ENE gives 2+4 = 6. So far so good... N=1, NE=2, E=4. We haven't used 5 so let's try assigning 5 to SE. ESE = 5+4 = 9. Next number is 6. Assigning 6 to S gives 6+5=11 for SSE. Assigning 7 for SW gives SSW=7+6=13. Assigning 8 for W gives 8+7=15 for WSW. 9 for NW gives 9+8=17 for WNW. Now the critical case of NNW. That's 9+1=10, which we haven't had yet so that's fine!
Let's tabulate this.
- N = 1
- NNE = 3
- NE =2
- ENE = 6
- E = 4
- ESE = 9
- SE = 5
- SSE = 11
- S = 6
- SSW = 13
- SW = 7
- ESW = 15
- W = 8
- WNW
- NW = 9
- NNW = 10
So the table looks like this.
- N
- NE
- NNE
- E
- SE
- S
- SW
- W
- ESE
- NNW
- SSE
- N/A
- SSW
- N/A
- ESW
- N/A
So we have a table of 16 entries rather than 256. Great!
-
Maybe.
-
1
-
-
Need to think out how that would work.
-
Probably C++ (Arduino IDE) as I know that best.
-
2 minutes ago, tekkydave said:
Have you considered storing your readings in a database. Then you can split the system into 2 parts;
1. A part based on the ESP32 that simply takes readings & logs raw data to the database
2. A front-end based on a pi or pc that displays the data. This can be more powerful for the processing required. Having the data in a db also allows you to keep a history of your readings. I now have readings going back to 2016 in my weather db.
That's my usual way of doing things but I need to get readings from the ESPs more automatically. ATM I'm just using a browser (Firefox) to read each ESP manually. This current method will do for now - far better than nothing.
-
2 minutes ago, JamesF said:
Actually you don't need a 256-entry table, because most of those entries are invalid. For example, assuming the pins are connected in sequence around the compass and, say, the pin giving value 4 is "on" then the only other pins that should also be possible to see "on" are either 2 or 8. Therefore any input that is not a single pin or a pair of adjacent pins is not valid and can be discounted.
James
That's what I was thinking but ATM I can't think of a better method. I'll get my thinking cap on!
-
Do you use a Real Time Clock with that James?
-
Looking at the wind vane calculations... I will have 8 digital inputs to the ESP32 two of which may be on at the same time. A "sledgehammer" approach would be to assign values of 1, 2, 4, 8, 16 etc. and then use a look-up table to convert to 16 values 0-15. This table would have 256 entries. I'm wondering if this would put a strain on the ESP32. Guess I can try it and see. Then Consensus Averaging with magnum maths and put the result in the HTML string.
-
In parallel with thinking about sensor locations I'm looking into the coding.
The trend in atmospheric pressure would be a useful extra and quite easy to do. Maybe max and min temperature but there would be a need to reset it.
For the wind instruments, instantaneous wind speed has little meaning. I'll probably average over 5 minutes. Data for mean speed and gust would be useful. The wind direction is rather more complicated. Firstly the read switch on/off reading has to be converted to one of sixteen. Then this would be smoothed with Consensus Averaging. It would be nice to generate a Rose Chart but that will have to be for the future.
-
Seems the "easy" places to put the Stevenson screen would not be good!
The north obsy wall, while shaded from the sun would not allow much airflow. On the wind sensor pole would suffer from heat from the black rubber roof of the obsy. Same with the ASC pole.
Here's a rough aerial view courtesy Google (a few years old). The rough ground cover and the whole of the area is currently overgrown with thistles but will be cleared. I'm thinking perhaps on a fence post on the boundary where I took a tree down might be as good as anywhere (if within WiFi range). The greener area is my property - the not so green area is my neighbours field.
-
The prevailing wind is SW. The observatory is about 15° off east-west, in a clockwise direction viewed from above. The wind sensors are on the SW corner in this photo. The long wall with the ASC pole attached is where I was thinking of putting the Stevenson screen. Met Office suggest a height of 4ft (1.2m) but pics of lots of weather stations show it at all sorts of heights. Maybe it doesn't make much difference
-
Have you any comments about the location of the Stevenson screen Wim?
Weather Station Ideas
in DIY Astronomer
Posted · Edited by Gina
Yes, I was wondering about the cable resistance problem. I shall have to look into the current requirements. I think the weather units will be under 100mA. Mostly the other devices are RPi boards which need around 2A as I recall which adds up. Maybe it's a case of just running 5v for the weather station units. These require only 5v and not the 13.8v whereas the imaging systems require both.