Ambient Weather Rain Gauge New Feature

 One problem I have had with the Ambient Weather system in the past was the lag time from the start of a rain shower until I actually saw any indication on my system that it was accumulating. The reason for this was that the weather station had to register a count, which got sent to the console about every 16 seconds. The console then would send this info to the Ambientweather.net system online once a minute at the most. Then my system had to get this info from the online account about once a minute before I would see the it was raining on my rain gauge display. The total delay could be as much as two to three minutes.

I found that the console recently had a feature added by which it could send data immediately after getting it from the outside system and send it to a local http client. I worked on getting this to work for me for some time. At first, I tried to get it to send to my Windows computer but was unable to get an app on the computer to collect this data. I then tried to get the data sent to an Arduino set up as an http server and it took a lot of work before I was finally able to get this to work.

This was great but I had a lot of trouble getting the address programmed into the console. Then I had trouble keeping the console connected to my local router. It seems they have trouble with 5ghz systems or mesh routers that provide both 5G and 2.4G signals. When it did work, it would average about 24 seconds to get the rain data, because many of the transfers took 31 seconds instead of 16.

With a little digging, I found a radio receiver that was supposed to work on the 915Mhz band the console worked on and I would be able to intercept the signal straight from the outside device. It took a lot of work, first to get the radio attached to the correct data ports on the ESP32 device I was using. Then I had to get the device to recognize the data packets and reject all of the extra noise the radio was picking up.

Slowly I was able to get the radio working reliably and get a steady flow of data. However, I found that the outside device only sent a count of tips of the rain sensor and that the console was keeping the totals. I had to develop code to read the data and convert it into a rain rate. That signal was more close to the 16 second rate that was supposed to come from the console. I worked this device into my overall system with my wall rain gauge display and my watch rain gauge.

I had used MQTT for a lot of the intra-device communications but with this new device, I switched over to using HTTP for data transfers within my home system, only using MQTT when I traveled with my phone and my watch. Since I'm using a free, serverless service from HiveMQ, I am limited in the number of bytes of data I can move so I have cut that way back.

Now, if a rain storm starts, I get a notification within less than a minute. I also cut back the rate calculations from the standard 10 minute average that AW uses to only 5 minutes. The rain storms we get here in Florida are usually on and off within minutes and taking 10 minutes after the rain has stopped for the rate to drop to zero was too long. I also changed the alarm to only come on when the rate exceeds 0.1 inch per hour. Little drizzles were turning it on and off too much.

Ambient Weather Rain Gauge

About 8 years ago, I bought an Ambient Weather weather station so that I could monitor the weather at my home while I was away. I have had it set up at three different homes in the same area since then and it has worked very well for me. It collects the information and then sends it to the "cloud" once a minute. I can then look on their website and see the current and historical information. I have loved this, especially when we have had some significant weather events, like a glancing blow from a hurricane (direct hits mess with the power and internet access, so data is lost then. 

 Although the device gives me this data on their website, I decided I wanted the current data in a different format on my phone where it would all be on one dashboard. The data can be queried through an API they provide and I have become well versed in writing Java apps for my Android device over many years, so this was easy for me to do. In the past year, I realized the weather event I was most interested was rainfall. The device measures it well and keeps charts and graphs of events over a one month period and less detailed information over a year. I wanted to have up-to-date rain information at a glance in my home, so I created a rain gauge app to work on an Android tablet and placed that on the wall. It alarms when rain starts and ends so I am alerted to the changing weather outside. 

 Since the rainfall totals accumulated only extend to the month, I also wanted to keep yearly and (meteorological) seasonal totals. To do this, I created an app for my Windows laptop that would store the historic data by day, week, month, year and season in a file. It could then distribute this information via messaging (MQTT) to the tablet gauge so all of this info is available at a glance. 

 As I am always looking for a new programming challenge, I decided to see if I could get this information to an even closer, personal device; my watch. I've had several Android smart watches over the years, but I've never tried putting an app of my own on them. Android Studio, which is my programming platform, has Wear OS capabilities. So I created an app and started working on what I wanted it to do. 

 When I started, I discovered that Java is not the programming language that is desired for Wear OS apps, rather Kotlin. I had not programmed in Kotlin before, so I had to do some studying on the differences between Kotlin and Java. As it turns out, Android Studio is very good at helping out with syntax and coding. I was able to import modules I had already composed in Java and convert them to Kotlin. Except for small changes I had to make, this was very simple.

Android Studio was also able to create companion Wear and Mobile apps, something needed to get the watch and phone to communicate with each other. I was then able to create a Rain Gauge App for my watch that displayed all the same info as the wall rain gauge.

As I was doing this, I discovered another aspect of smart watches I had not encountered; complications. Although it sounds daunting by its name, these are areas of the watch face that contain information other than the time. They can have pictures, text, and range data. I realized that I could go one step further with my personalization of the rain data by putting it right on the watch face. Android Studio heled me a lot with this coding as well. Soon I had the data right there to see at a glance. Also, tapping on the complication info brings the entire rain gauge app to the display.

I can get notifications on my phone when it starts or stops raining, notifications if one of the data feeds stops sending in data, and even, something I have had trouble with, a notification when my watch battery is running down. Although the watch is supposed to do this itself, it has only worked sporadically at best.

This has been a real adventure in programming for me and I can't wait until the next feature I decide to add.

New Automenorahs and Communications

OK, it has been years since I created the old Automenorahs, which were designed mostly for Hannukah (as Hannukias). As time went on, I decided I wanted to do more with them to be able to use them throughout the year. In the Jewish religion, the Menorah is actually a religious strudture with 7 lights and is usually lit on religious holidays. Also, there are the two candles which are lit on every Shabbat (starting Friday night and continuing until Saturday night). So, I decided to expand threir programming to lights two lights each Shabbat and 7 lights each Jewish Holiday other than Hannukah and Shabbat. This required me to do two things. The first was to be able to accurately set the time and date and have the Automenorah maintain its accuracy over long periods. The clock chip was fine but it had to be programmed initally and then hope it would remain accurate. I found this to m=not neccessarily be the truth. I found that Arduino was starting to make some chips with wifi and bluetooth capabilities. Some of them were even smaller than the Arduino Uno boards I had been using. I also found they had on board 3.3VDC supply outputs and I could use this to supply current to the led lights without and external circuitry. I started experimenting with the wifi code and was able to get the current time and date from an online NPT server and query a Google server for time zone and DST information. This made it possible to program the Arduino to get the current time and date info on start up and use its internal clock to maintain this, allowing a resync with the internet at regular intervals (once an hour). The other thing I needed was a Hebrew lunar calendar to tell me when the holidays occurred. Shabbat was easy because it was just once a week on Friday but Rosh Hashana, Purim, Yom Kipper, etc was a different story. Went looking for software and was able to get a Gregorian to Hebrew conversion working so I could tell when the holidays start and end. Another thing I wanted to accomplish was to be able to create a dashboard app for my phone that would show me that the AutoMenorahs were working, maintaining acurrate time and tracking the holidays. I also wanted to make it possible to send information to the devices to set a "lights out" time which would allow lighting over night to be at a minimum and to set other parameters like the length of certain holidays. I had tried simple serial communications but this required the device be plugged into the computer. I also tried the Arduino Cloud with mixed results. Although II cannot remember why right now, I decided that was not going to work. Eventually I became aware of MQTT communications and, through much experimentation, was able to get the devices to work with my Android phone. I used a free test server called "test.mosquitto.org" for the broker of the messages back and forth. This worked well except that the server seemed to have frequent outages, usually on weekends. I had also come across HiveMQ, which had a free option but the communication protocals were different and somewhat escaped me for a while. In the meantime, I had started experimenting with a digital rain gauge based on my Ambient Weather Station I had had for several years. I wanted to display its rain output in a conspicuous display on an old tablet. This was pretty easy but I also decided to add MQTT to it as well to communicate with another rain gauge app on the Windows Desktop. It keped rain totals beyond what the Ambient Weather system did. It only kept totals up to the month and I also wanted to keep yearly and seasonal totals. The desktop app kept that stuff in a file and distrubuted it to the tablet for display and also to another app on my Android phone that displayed rain totals for the entire year by month and season. I finally spent some time with the HiveMQ server and the code changes I needed to work with it. I had to understand certificates and why the were important and how to incorporate them into my code. now that is all working with the Automenorahs and the Rain Gauge. I also created a cute little LEGO Menorah that uses the same code with an Arduino ESP32. I had also been thinking about IoT capabilities to be able to take a completely new Automenorah and to be able to set it up in a new location with a foreign internet connection in a different time zone with different DST requirements. After installing some IoT devices in my house I thought I had an understanding of how it should work. So I used the Bluetooth LE connection on the ESP32 to set up an inital connection and give the device the credentials it needed to connect to the intenet and the location information (City and State). I ended up also working with some ESP6822s that did not have Bluetooth LE but I nade them work using wifi communications.

The Barndoor Tracker Revisited

Well, I got a chance to put the Barndoor Tracker to use this summer. On August 21st, I was privileged to observe the Great American Eclipse from Glenrock, WY. The weather was sparkling, except for some high, wispy clouds that showed up just in advance of the eclipse and continued to grow a bit right after. However, photographic opportunity was perfect and the eclipse occurred right on schedule.

In advance of the eclipse, I did a considerable amount of testing and work to get the tracker properly aligned to track the sun. I learned a lot about both astrophotography and the tracker. One thing is that the tracker has got a bobble to it. It tracked ok but not perfectly. The sun stayed in frame but it would move a bit from one picture to the next. I was taking pictures every two minutes and the sun would move one way and then the other. I think that there were two things that contributed to this. One was that the geometry is too complex. I plan to rebuild it this winter to align the pivot points with the lead screw. This will get rid of some of the calculations needed and also will make it easier to get the pivot points straight. That leads to the other possible problem, that at least one of the pivot points is not straight, which makes the door open at an inconstant rate.

The other thing I learned about the tracker was how to get it aligned. I had to do it the night before by sighting on the North Star (Polaris) with my camera attached to the tripod and shooting a timed exposure of about 30 second. Then I zoomed in on the image and adjusted the tripod to get the star to align perfectly with the center of the image. When this was correct, and the tripod was completely locked down against movement, I retired and, in the morning, attached the tracker to the tripod without disturbing it. After this, it tracked quite accurately, except for the aforementioned wobble.

So the other day I was at the Fry’s here in Wilsonville, Oregon, where we are visiting now that the eclipse is memory and photos, and I bought a Raspberry Pi. I guess I will be exploring this next and figuring out what I can do with it. Fun.

Barndoor Tracking Mount Part 5

The tracker is pretty much finished now and has been field tested with excellent results. The electronics are mounted on the bottom and covered by a shell, the lighting has been added where it is visible from the top, and I have added bubble levels to aid in getting the platform level and at the proper angle for the latitude. I have run some test programs which run the platform through some known angles and it came out spot-on. The only difficulty I have had is in setting up the tracker on the exact polar axis. So far, I have not used it in a location where I could see Polaris. I have used a compass and measuring angles with my phone to set it up, with mixed results. There is a little movement of the images but not much, many because I performed mostly short exposures. However, to aid in this setup, I have added two bubble levels. One is attached along the long axis to get the bed level. The other is adjustable on a protractor so it can be adjusted for the current latitude. Then I should be able to use the bubbles to set the correct angle. I would still need Polaris to site on or a compass to get the azimuth angle correct. This would also have to be the way to set up in daylight (as I will be using this tracker during the solar eclipse this summer).

Here are some final pictures.

Barndoor Tracking Mount Part 4

I have been having some problems with the stepper motor and the Sparkfun stepper driver and have finally gotten it all straightened out. The motor was having periods when it would sputter, misstep, and sometimes not even run at all. I finally reached the conclusion that the motor or the controller was bad. Since the motor was from surplus, I decided to replace it. It was not very expensive and I was able to find an exact replacement online so I did it. The new one seemed to work better, for a while, but then I started having similar problems. I was looking into replacing the controller but, in doing this, I found some documentation on the board that I had not seen before. In the margin notes, I found the recommendation that some of the inputs that were not being used in control be either connected to ground on Vcc (+5vdc). The ones that were listed included one to put the controller to sleep and another that was a reset. The third was called PFD and I did not examine its function closely but, I had not seen anything in the sample hookup documentation about these pins. However, I tied all three to Vcc and now everything is working fine.

Now I have a nearly completed mount. I just have to put on the part that will hold the camera and I will be ready for some field testing. However, first some more bench testing was in order. I attached a limit switch to allow the door to have a seekable home position. This ties to one of the Arduino inputs and, by doing a little testing. I found this to be a highly repeatable location even though the button I used seemed to have a lot of play to it. A second button was attached to be a command switch. The command button switches the program between the different modes: STANDBY, which is the default start mode and where the controller is just waiting for input, RETRACT, where the door is seeking the home position, READY, where the door is home and waiting to start tracking, and TRACKING mode.

After installing the home position switch, I had to repeat some of my measurements to determine the lead screw leg distance for the home position (see the last installment to see where this measurement is used in the calculations). I then went back and ran the test to measure the angles of individual steps that should each open the door in one degree increments. I got much better measurements, although still not as perfect as I would expect. More testing and measuring might be in order.

Next, I created a test for the command button. The button throws an interrupt to the Arduino board. This sets a flag that is then detected and reset in the program. Everything checked out fine so I incorporated the command button into the final Barndoor program and implemented each of the modes of operation. Finally, I was able to run the door through its paces. The flowchart follows. Click on it for a bigger view.

Next, I will have to finish up the packaging for moving to the field. I think I will mount the circuitry on the bottom of the mount and then route the cabling so it does not get snagged. I will likely also mount the lighting where it is easily viewable. My power supply for the field will be an automotive jump starter and tire inflator which has both a USB power port and a 12V power port. The USB port will power the Arduino through its USB port and 12V will power the stepping motor circuit. I have already tested the door using this power source and it is robust enough for use in the field.

Barndoor Tracking Mount Part 3

So I had to back up on something I posted last time. I showed the stepper motor with an 8mm screw and two intervening shaft couplers. Well, after ruminating on it a bit I realized that the shaft coupler that was flexible would not work with my design. I needed one that was ridged, otherwise too much play would be added into the system and accuracy would suffer. I knew that the motor shaft is 1/4 inch and the lead screw is 8mm so I looked for a coupler that would match those sizes and, surprise, there is such a thing. $6 later I have one. So now I was ready to start building the mount. The two “doors” are 3/4 inch oak and there are three hinged areas that hold the two doors together and also allow the motor and lead screw nut to stay aligned as the door is opened and closed. I showed a picture of this design in the last post so I took to building. The RV resort where we live in the winter has a nice woodworking shop so I had everything I needed.

I started cutting and shaping and, with a couple of restarts due to misplaced components and the purchase of another piece of wood to make the hinges, I was able in a few days to have put together the mount. Here are some pictures of the components and the final assembly.

Next came a test of this set up. I created a program for the Arduino to move the door in one degree increments from the closed position to the maximum open position. I immediately found a problem. Measurements showed it to be opening too far, about 1.3 degrees per increment. I did some modeling of my code in an Excel spreadsheet and it looked good. After some more testing I finally discovered that the lead screw, which I could have sworn was a three-start thread, was actually a four-start thread. This meant that instead of moving 6mm per revolution, it was really moving 8mm per revolution. This made a big difference and I was able to just change a variable in the program to correct it.

I forgot to mention that a crucial part of getting the door to open correctly was making accurate measurements of the finished device. I need to know the exact dimensions from the main door hinge center to the motor block hinge and the lead screw nut hinge. I also need to know the distance from the lead screw hinge center to the center of the screw and the same from the motor hinge to the center of the motor shaft. With all of those dimensions I can there create a formula that gives me the angle between the two door halves and can compute how far the lead screw nut has to be pushed out to open that angle by a specific amount. The same formula then can be used to determine the rate at which to step the motor to get the door to match the sidereal angle of the earth.

Now, examine this diagram:

If the vertex of a-b is the main door hinge, the vertex of a-c is the lead screw nut hinge, and the vertex of b-c is the hinge of the motor block, then the angle C is defined by the formula:

So “a” and “b” are measured constants and “c” is variable as the lead screw moves. However, the screw does not pass thru these points so there is another formula to find “c” for different steps on the lead screw. The geometry of the lead screw with respect to “c” is described in the following diagram and formula:

The lead screw nut (“n”) leg and the motor base (“m”) leg are always at right angles to the lead screw (“L”). Note: this is the reason the flexible motor shaft coupler was not appropriate. So the Pythagorean Theorem is used to determine the length of “c” depending on the position of the nut on the lead screw. By combining these two formulas the angle “C” can be determined for any particular step of the motor and can be matched then to the sidereal angle of the earth starting at the home or closed position of the door.

Next, I have to attach a switch to mark the home position and program the tracking algorithm for the Arduino. More on that in the next installment.