Recent Posts

Pages: [1] 2 3 ... 10
Other Weather Station Hardware / Re: B-L Sun Shine Recorder
« Last post by PaulMy on Today at 09:46:50 AM »
Coming up to 6 years of using the B-L Sunrecorder

Visit and have a look through the Users Manual

Tech Corner / Re: IE 11 issue
« Last post by ALITTLEweird1 on Today at 09:13:34 AM »
Yeah,  i removed the 2nd router and put a switch in. That fixed the problems.
Well, if the 7' above your roof is set in stone then the only thing (as far as I know) that the VP2 will do better than the Vue is to allow additional sensors such as soil/leaf moisture, solar, uv, ???, to be added to the station.  If you garden or work with solar energy then the solar sensor would be nice to have, soil/leaf moisture sensor for gardening, UV...not real useful.  So, if you feel like the Vue has every sensor that you think you will need then it will suffice for wind data.

I agree with CW2274 that placing the ISS in that lofty location will be problematical regarding maintenance/repair....especially keeping the rain bucket cleaned out.  The new Davis units are shipping with the new buckets that have the bird spikes (make sure you get a current version) so that will help a little.  In a populated, residential-type area most people have to compromise on their siting, it's somewhat of a "given".  Even folks in the country have issues finding the perfect location and being able to elevate the anemometer up at the recommended height (33ft/10m).  But, installing the ISS in a hard-to-get-to location is known to cause the "I'll do that next weekend" syndrome. 

If it was my station, and it was mounted on the roof, I know that the biggest issue would be keeping the rain bucket clear.  The birds consider it their own personal Porta Potty.  But, other things happen, too.  I will be working on my anemometer very soon (waiting on parts and for a very wet weather system to move out...also have the new style bucket coming), but mine is on a pole that is mounted on a 4x4 post via some swivel braces so a short ladder, undo one brace and loosen the other one and the pole will tilt down to the ground.

Think hard about the maintenance aspect of the ISS.  But, for only wind, I feel both will give you more or less the same data...when placed in the same position.  The VP2 will not have as much body/housing in close proximity to it as the Vue will....slim anemometer design versus the Vue's bulk of the entire ISS sitting just below the anemometer.  Since your research is "wind" I thought I'd mention that last point...might make a difference if you data needs to be as precise as possible.  But, everything is a compromise...we just do the best we can.

I'm curious, where was your Acurite situated?

Best wishes,
See my remarks in another thread.

Ed: I disagree with that description of updates. I have extensively tested (with my own code) that updates to can be made in a matter of 1-3 seconds. I have also confirmed, through network sniffing, that my ObserverIP (OIP) completes the request and receives the response within that time frame (rare exceptions noted). In fact, the OIP software even closes the connection with a FIN/ACK FIN/ACK sequence interchange with immediately after receiving the response, so still within 1-3 seconds.

I have a good and relatively fast connection, but WU's ability to respond that quickly proves that longer delays are almost for sure a function of either network performance (i.e. unrelated to the ObserverIP firmware), or a bug in the ObserverIP code. The former may well be the case for users with a slower connection and larger geographical distance to servers, but will in most cases still take less than 5-10 seconds.

With respect to the latter (bug), I have communicated about this to you and the tech team extensively. Part of the problem is that the connection reset (RST packet) that not only should not (need to) be sent, is also not sent until some 18 or so seconds after the response from has been received. The small network trace posted by @billybob shows that delay (although it does not show the time of receipt of the response, but my own network traces do), and I have extensively communicated detailed network traces about this over the past several weeks.

I am convinced there is a bug in the code that causes this delay because for some reason or other the RST is not requested until the next scheduled update interval (which as noted was always around 15 seconds). Meanwhile (because it has to hold on to the network connection session to be able to issue the RST), it effectively blocks a new update from going out. Changing the update interval to 1 minute works around this problem, because by then the RST has taken place and the session has been freed up for re-use, but results in an update frequency less than originally implemented, and for some less than desired. Again, the other thread I referenced has a little more detail on this. The other key issue is that the issuance of the RST is incorrect with respect to documented TCP protocol (because a FIN/FIN sequence has already taken place, and no data was left in send or receive buffers).

Because of this change of update interval it is not the case, as you state, that is still updated once every 14 seconds, it is now once every 60 seconds (hard coded). It is correct that any updates are not affected by this. What is also correct is that indoor and outdoor sensor packages are still read-out approximately every 15 seconds, so sensor values are never older than that.
Ambient Weather Station / Re: Ambient ObserverIP list of bugs/known issues
« Last post by dolfs on Today at 04:01:33 AM »
Version 4.0.8 was released.

Notable changes:
  • If WU stationID and password fields are left blank no error is generated (as it was before). This allows a setup where there will be no upload attempts to WU at all. Previously this could only be achieved after a factory reset, which would clear the fields. Once the fields were set, they could no longer be cleared (due to the validation error message that would not allow empty fields).
  • As previously explained, successful (no timeout) requests to WU are needed to properly set the time on the ObserverIP. Since the feature was introduced where you can upload to ambient as well, or instead, time can also be taken from there, so as long as at least one is configured and working, your time will be correct(ed) shortly after a reboot. If you do not wish to upload to and also not to ambient, leave the fields blank and set the popup to "no upload". This will put the ObserverIP in a mode where it will still make a request to WU four times a day, at midnight and then every 6 hours, on the hour. The request itself will fail to store data at due to the blank stationID and password, but the time will still be delivered in the response and will be used to correct the RTC on the ObserverIP. The 6 hour interval was chosen to keep the time correct to one second or better within the known accuracy of the on-board RTC.
  • Overall performance was improved and stabilized with respect to the ObserverIP web page serving. This is not as important to a casual user, but is quite important to users of MeteoBridge or WeatherBridge. Previously I had observed occasions where the OIP performance would slowly degrade and response times to the MeteoBridge (hard wired using 100Mb connection on same network) went from a routine 3-6 ms slowing increasing until it would exceed 100 and then 200ms. This behavior has stabilized and I consistently see 3-6 ms responses.
  • update frequency has been reduced to about once per minute (although it is not precise), from a previous 30 second interval and an advertised 16 second interval. This was ostensibly done to create more stable network behavior. In my opinion it effectively works around a bug in the code, at the expensive of this update interval. I also believe the problem might not exist in scenarios where either or would be the sole upload destination (i.e. not both), but I have no solid evidence of that.
  • Despite the update frequency/interval for both services now being at once per minute (or longer for if configured like that), the OIP still receives data from the indoor and outdoor sensor packages more frequently, approximately every 15 seconds. This will be reflected on the LiveData page, for example. It also means that, once an upload occurs, the data is generally not older than 15 seconds.
  • A bug was fixed where if both uploads to and were configured, the latter would be sending a request body of non-zero length containing partial content from the request headers to (shared buffer overwrite with incorrect length management). This appeared to not have any negative consequences, but it was sloppy and has been fixed.

Aside from testing that I perform for Ambient and Fine Offset, I operate my OIP without uploads active to either or as I use my MeteoBridge to do this instead. This way all uploads, including those to CWOP etc. will use the same sensor values, as they all go through the same calibration curves and altitude setup. MeteoBridge is able to read sensor values from the MeteoBridge ("scraping" the LiveData page) much more frequently, to take advantage (if you are so inclined) of the fact that the OIP internally still receives and updates the outdoor and indoor sensor values approximately every 15 seconds.
Custom Website Templates / Re: Meteotemplate - new free website template
« Last post by Bashy on Today at 02:32:58 AM »
Morning, just tested the paypal button and i get this error at paypal,  email addy is correct, triple checked it.

PayPal cannot process this transaction because of a problem with the seller's website. Please contact the seller directly to resolve this problem.

Also, as mentioned a few days back, the reports/extremes is broken
Meteohub/Meteobridge / Re: Meteobridge Auto reboot
« Last post by ronmis on Today at 12:14:08 AM »
makes complete sense. I tried out the auto reboot feature and it works well, then I removed it. I'd rather reboot manually and make sure it comes up and works well.
GRLevel X Software / Re: vs AllisonHouse
« Last post by Farmtalk on Yesterday at 11:38:27 PM »
Another Allisonhouse fan. Service is great, and their data is rock solid dependable.
WeeWx is written in Python (2) so that any platform that can run Python can run WeeWx.
Davis Instruments Weather Stations / Re: Confusion with DFARS
« Last post by CW2274 on Yesterday at 10:11:48 PM »
So SHT11 is a fairly old style sensor?

What info is need to see if it will support a later sensor?
Yes, over 11 years.

None, as it will. If you enjoy accuracy, the 31 is in a different league compared to the 11, especially in the linear response to very low and high humidity.
Pages: [1] 2 3 ... 10