<link rel="self" type="application/atom+xml" hreflang="" href="gemini://benjaminja.com/tags/weather-station/feed.xml" />
<link rel="alternate" type="text/gemini" hreflang="" href="gemini://benjaminja.com/tags/weather-station/" /><id>/</id>
2024-05-21T22:13:26Z
Hugo 0.129.0
<title><![CDATA[Converting from teensy to arduino]]></title>
<link rel="alternate" type="text/gemini" hreflang="" href="gemini://benjaminja.com/log/2024/05/21-station_conversion/" />
<id>gemini://benjaminja.com/log/2024/05/21-station_conversion/</id>
<updated>2024-05-21T22:13:26Z</updated>
<summary type="gemini"><![CDATA[For the past few days, I have been converting my weather station firmware to use an Arduino Atmega328P chip instead of a teensy Arm Cortex M7 chip. In my last post, I found that the teensy is significantly overpowered for the job and it could be contributing to why the temperature readings are consistently so high.
]]><![CDATA[For the past few days, I have been converting my weather station firmware to use an Arduino Atmega328P chip instead of a teensy Arm Cortex M7 chip. In my last post, I found that the teensy is significantly overpowered for the job and it could be contributing to why the temperature readings are consistently so high.
I want to discuss the logic that the station does and how it has become difficult to squeeze that same logic into a much smaller device.
On the teensy, the logic was split into a few parts:
This is quite a bit of things for the station to do and is definitely way too much for the Arduino to handle. Instead of keeping a history of the data on the station, the base station will do most of the processing. I figured this would be a relatively easy process, but I have forgotten just how under powered the Arduino is.
The Arduino has 32kB of flash and 2kB of ram. 32kB is pretty small, but that isn’t really a big deal. You have to have a really big program to surpass 32kB. I don’t even think the program for the teensy was bigger than 32kB. The real problem is with the ram. 2048 bytes of ram is all you get. That’s including static variables, stack variables, and the heap.
When you compile for the arduino, it gives you a helpful graph saying how much ram and flash your program uses. For flash, it just doesn’t need to get bigger than 32kB. The ram is a different story though. The graph that is provided for ram shows only static variables that are pre-allocated. So if you used 1kB of ram in the graph, then you really only have 1kB of ram for the stack and heap. So you really need to be careful about memory at all times.
This is one of the reasons why I don’t particularly like C++ for embedded since when using classes you sometimes never really know how much memory you might end up using. Though the embedded community has made C++ feel a lot better than I think how modern C++ feels. I can’t wait for embedded Zig to mature, but it is still at the point where only like 5 boards are supported, and even then, only registers are available which make programming a nightmare. (I’ve really only tried to get into embedded Zig once, and probably missed a bunch of things. I would love to be proved wrong about embedded Zig)
With my adaption to Arduino, I have reduced the responsibilities significantly for the station.
While the Arduino has the same basic responsibilities, it is now performing less calculations and storing less data in ram. The biggest changes are to the wind. Before, the teensy stored 600 floats/uint8 for the wind gust/directions at a rate of 1 sample per second for 10 minutes. That alone is 3000 bytes of data and 1.5 times the total ram capacity of the Arduino. And that is not including wind averages.
I’ve since realized that I could significantly save space by storing only the last minute of data (60 samples) and instead of calculating the speed on the chip, it just counts the number of ticks during the sample. I could store each sample as a uint8, and store the wind direction also as a uint8. This makes the cache only 128 bytes long.
You might be thinking to yourself “Self, how does one get 360º to fit in 255?” I’m glad you asked! My weather vane can only read 8 cardinal directions. “Great, so the direction can fit easily in a byte!” Not exactly, 10 times a second I take a reading from the weather vane. Convert it to x/y components and average it out for the sample. I then use an atan2 LUT to convert the x/y component back into an angle. The LUT is a 21x21 table ranging from [-1.0, 1.0].
=> 🖼 Image of the LUT—Colorized
Because the LUT is built with steps of 0.1, there are 441 possible outputs, but there are only 232 angles that are produced. So instead of outputting the angle I output the value for another LUT which converts from values [0,232) to [-174,180]. This way I can store a more accurate wind direction within a single byte. The base station will have to convert the angle index back into a real angle, but I feel like it is a pretty interesting way to get more detail out of the sensor.
=> 📭 Message me | 📝Or mention this post
]]>
<category term="projects" label="Projects" scheme="gemini://benjaminja.com/tags/projects/" />
<category term="weather-station" label="Weather-Station" scheme="gemini://benjaminja.com/tags/weather-station/" />
<published>2024-05-21T22:13:26Z</published></entry>
<title><![CDATA[Weatherstation Update]]></title>
<link rel="alternate" type="text/gemini" hreflang="" href="gemini://benjaminja.com/log/2024/05/16-weatherstation-update/" />
<id>gemini://benjaminja.com/log/2024/05/16-weatherstation-update/</id>
<updated>2024-05-16T17:55:36Z</updated>
<summary type="gemini"><![CDATA[It has been a little while since I last wrote about my weather station–almost a whole year in fact. I wrote about how I would go about communicating between my raspberry pi and my micro controller.
]]><![CDATA[=> /log/2024/05/16-weatherstation-update/24-03-18_13-30-12_fly_.jpg 🖼 Photo of the weather station
It has been a little while since I last wrote about my weather station–almost a whole year in fact. I wrote about how I would go about communicating between my raspberry pi and my micro controller. I decided I would use CAN bus to do all the communicating. It turns out though that CAN is really difficult and designed to work well when you have multiple devices communicating over the same wire. Think long distance i2c. Since I’m just doing peer to peer, CAN ends up being a bit over complicated for my use case.
Shortly after writing my post, [Fripster] sent me a message saying that I might be better off using RS422. He was definitely right and I switched over to that right away.
=> Fripster
In my project, I’m specifically using differential TTL (transistor-transistor logic) where each UART is split into two twisted wires where one is + and the other is -. At the receiving end, the pair is combined back together into a single signal. These twisted pairs make it so that the signal can go for a significantly longer distance without signal degradation. There has been a ton of work done to figure out how and why it works, but it’s basically just magic to me.
RS422 isn’t a protocol on its own. It is closer to a specification on how to physically connect two devices together. I’m not even sure if there is a standardized voltage designated for it, and if there is, I’m definitely not using it.
In order to actually communicate between the two devices, I came up with a binary extension to G-Code I called S-Code (I think it was short for Serial Code). Instead of commanding a CNC machine, I send custom codes to request codes be sent back or to save configurations.
The codes can be either in traditional g-code style, or in my own custom binary format. It supports 8, 16, 32, 64 bit integers, strings, and 32 or 64 bit floats. At the end of every binary code is an 8-bit crc.
You can learn more about it at [github.com/ttocsneb/scode].
I have been able to get the weather station up and running. It collects data, can display current conditions, and most importantly, is usable by non-technical people. Almost everything seems to be working with it. There is just one itsy bitsy problem. The temperature is readings are too high.
In the above graph, you can see that my station is higher than the airport temperatures by about 8ºF (~5ºC) on average. I ended up applying a constant adjustment to the temperature sensor to combat the issue. Just today, it was reading 72ºF (22ºC). There is absolutely no way it was 80ºF (27ºC) today. The constant adjustment isn’t a great solution though. You can see that the adjusted temperature can be higher than the airport during the day, and cooler during the night by a few degrees. Since the airport is by the lake, it is possible that the actual temperature differences between me and the airport are just a few degrees different, but I don’t know. I feel like there is something going on with the sensor or setup.
I have a few theories why the temperature could be wrong:
I have a feeling that the issue is coming from the teensy being too hot. When developing the software, I noticed that the chip gets warm to the touch. It’s not really something that I have noticed on other MCUs, though seeing that the Cortex M-7 is clocked at 600MHz, it’s starting to make sense why it gets a little warm. If it is warm to my touch, then it would make sense why it could affect the temperature sensors readings.
The ground plane on the circuit board covers the whole thing, so the circuit board is acting like a heat sync and since the sensor is connected to ground, a larger thermal load could be pumping heat into the sensor.
This doesn’t really explain why the actual readings would at times be close to the real temperature. I would think that when the ambient temperature goes down, there would be a larger temperature differential making it so that heat from the teensy gets taken away faster than when it’s hotter outside. This makes sense in my head, but I’m sure there is something wrong with my reasoning. The name science may be in my degree, but that doesn’t mean I’m any good at it.
If the ground plane is part of the issue, then I could redesign the circuit board to isolate the ground from the sensor from the teensy as much as I can, or get rid of the ground plane altogether.
It’s possible that direct sunlight on the enclosure could be causing problems, radiating heat into the enclosure even though the sensor is in shade. This doesn’t make much sense to me since the same enclosure was used to house the original commercial weather station.
If you have any thoughts on why I might be experiencing temperature issues, I would love to hear from you!
Another problem I have had is that it is impossible for me to flash the firmware to the teensy over serial. That means if I have a firmware update for the station, I will have to go up onto the roof, take down the machine, flash it, take it back up to the roof and hope that everything went smoothly.
I’ve looked into ways that I could reflash the teensy using different UARTs other than Serial0, but it seems that the bootloader is on another chip that is hardwired to the USB port.
I feel like the best option would be to use a different MCU altogether. I have a Arduino Pro Mini laying around which doesn’t have any onboard FTDI chip. I think that I would be able have the chip go into bootloader mode and flash it all through the existing RS422 interface.
――――――――――――――――――――――――――――――――――――――――
I’ve been thinking that with the temperature issue and inability to update the firmware, my next step in the weather station project would be to replace the Cortex M7 processor with an Atmel328P chip. It has a much slower clock speed of 16MHz and a much lower power consumption.
I’ve estimated that the teensy draws 90mA (0.3W) and the Arduino draws 6mA (0.02W). Some rudimentary calculations show that 0.02WH of power in a chip should yield about 5ºC of temperature change and 0.3WH of power in a chip should yield about 75ºC of temperature change. These are very rough calculations, but I think it shows that the teensy could very well be affecting the temperature readings and that an Arduino Pro Mini should have a much small impact on the temperature.
=> Site where I calculated temperature changes
I’ve already started working on transferring the logic from the teensy to the Arduino. It really shouldn’t be difficult. The most difficult thing will probably be converting from interrupts to PCINT.
=> 📭 Message me | 📝Or mention this post
]]>
<category term="projects" label="Projects" scheme="gemini://benjaminja.com/tags/projects/" />
<category term="weather-station" label="Weather-Station" scheme="gemini://benjaminja.com/tags/weather-station/" />
<published>2024-05-16T17:55:36Z</published></entry>
<title><![CDATA[Communicating with my weatherstation]]></title>
<link rel="alternate" type="text/gemini" hreflang="" href="gemini://benjaminja.com/log/2023/06/24-comms_with_weatherstation/" />
<id>gemini://benjaminja.com/log/2023/06/24-comms_with_weatherstation/</id>
<updated>2023-06-24T18:42:00Z</updated>
<summary type="gemini"><![CDATA[In my original plan for my weatherstation, I would wirelessly send weatherdata to a ground station. I have given up on this idea primarily because managing a rechargeable battery would introduce too many variables. Now, I have decided to have a cable that connects between the ground station and the sensors.
]]><![CDATA[In my original plan for my weatherstation, I would wirelessly send weatherdata to a ground station. I have given up on this idea primarily because managing a rechargeable battery would introduce too many variables.
Now, I have decided to have a cable that connects between the ground station and the sensors. I will be using an ethernet cable as the medium, but I won’t be using the ethernet protocol. Having a network card on the station is more overhead than I would like.
The original plan was to connect the serial lines directly. This is not a great idea, since plain datalines cannot go a long distance without losing integrity. Instead, making the lines differential twisted pairs—which ethernet is already made of—would allow for longer reliable distance. I just don’t know how I would convert a line into a twisted differential pair.
I discovered that CAN bus could be the better option for me. It stands for Controller Area Network, and is designed to be a light weight alternative to Ethernet. CAN is generally used in cars and in industrial settings.
Now I just need to come up with a protocol to manage the weatherstation. I’ve discovered a protocol called CANopen which seems very interesting. I’m currently stuck trying to decide whether I want to fully implement CANopen, or if I want to develop my own protocol that is inspired from CANopen. There is a lot of stuff that goes on with CANopen that I don’t necessarily need (particularly since I don’t plan to integrate the weatherstation with other CANopen devices).
There is a library for CANopen called CANopenNode, however I would have to make my own compatibility layer with it since no has done that for the Teensy4.0. It might just be better for me to design my own partial CANopen library.
Maybe I’ve gone too far into CAN, and would have been better off just using an Ethernet card. I’ve had fun working with CAN and CANopen, so I don’t think I have wasted my own time here, but sometimes I wonder if it would have been better to use a different board that has ethernet built-in.
=> 📭 Message me | 📝Or mention this post
]]>
<category term="side-project" label="Side-Project" scheme="gemini://benjaminja.com/tags/side-project/" />
<category term="weather-station" label="Weather-Station" scheme="gemini://benjaminja.com/tags/weather-station/" />
<published>2023-06-24T18:42:00Z</published></entry>
<title><![CDATA[My weather vane is now better than new]]></title>
<link rel="alternate" type="text/gemini" hreflang="" href="gemini://benjaminja.com/log/2023/04/30-repaired_weather_vane/" />
<id>gemini://benjaminja.com/log/2023/04/30-repaired_weather_vane/</id>
<updated>2023-04-30T17:12:00Z</updated>
<summary type="gemini"><![CDATA[Yesterday, I wrote about how I broke and repaird my weather-vane After it got repaired, I was able to get the sensor working in software. Everything worked, but there was one thing odd about the sensor.
]]><![CDATA[=> /log/2023/04/29-broke_weather_vane/ Yesterday, I wrote about how I broke and repaird my weather-vane
After it got repaired, I was able to get the sensor working in software. Everything worked, but there was one thing odd about the sensor.
To give some background, the sensor can tell the direction of the wind by triggering one of 8 magnetic reed switches each connected to a resistor. If I measure the resistance of the sensor, I can tell which direction the wind is blowing.
The east resistor measured infinite ohms. In hindsight this is obviously a problem, but I thought that everything was normal until after I did my repair. Why would there be a reed switch that connects to an infinite resistor? This is the same as having a switch connected to nothing.
I took apart the sensor once again to look for any damage. I was only hoping that I wouldn’t have a busted reed switch. After some continuity testing, I found this on the east sensor:
=> 🖼 A reed switch that has been pulled off the circuit board
This must be something that has been broken for over 6 years now. I was able to make the repair, luckily it was pretty simple. Just a jumper from the resistor to the reed switch.
I can’t describe just how happy I am about this.
If the wind points between two of the sensors, then it will no longer think the wind has spontaneously pointed east.
=> 📭 Message me | 📝Or mention this post
]]>
<category term="projects" label="Projects" scheme="gemini://benjaminja.com/tags/projects/" />
<category term="weather-station" label="Weather-Station" scheme="gemini://benjaminja.com/tags/weather-station/" />
<published>2023-04-30T17:12:00Z</published></entry>
<title><![CDATA[Whoops, I broke my weather vane]]></title>
<link rel="alternate" type="text/gemini" hreflang="" href="gemini://benjaminja.com/log/2023/04/29-broke_weather_vane/" />
<id>gemini://benjaminja.com/log/2023/04/29-broke_weather_vane/</id>
<updated>2023-04-29T17:47:00Z</updated>
<summary type="gemini"><![CDATA[I am working on my weatherstation project now, and I’m going to finish it for real! Yesterday I was opening up the weather-vane to reverse-engineer the board it has and make sure what I already know is correct.
]]><![CDATA[I am working on my weatherstation project now, and I’m going to finish it for real! Yesterday I was opening up the weather-vane to reverse-engineer the board it has and make sure what I already know is correct.
I was able to get my picture and put it all back together; there was only one problem. The sensor no longer worked! It turns out that when I took the board out of the housing, I also pulled the cable a bit too hard and broke the connection to the board, whoops.
Fixing the board should be pretty easy, I just have to remove what’s left of the wires, and solder the wires back in. To make sure that the wires don’t fall apart again, I decided to use solid core wires and connect the cable to that.
Everything went pretty well until I accidentally ripped one of the pads off the circuit board, whoops. I am just lucky that the pad I pulled off had a simple connection that I could easily bypass.
I was able to fix the sensor just fine. It looks a little silly, but that’s ok. The one thing that I’m more annoyed at than anything else is that I didn’t need to take apart the sensor. I had already done that around 6 years ago, and uploaded it to my wordpress blog.
=> My blog where I analyzed the weather-vane.
=> 🖼 Back of the repaird weather-vane
=> 🖼 Front of the repaird weather-vane
=> My weather vane is now better than new
=> 📭 Message me | 📝Or mention this post
]]>
<category term="projects" label="Projects" scheme="gemini://benjaminja.com/tags/projects/" />
<category term="weather-station" label="Weather-Station" scheme="gemini://benjaminja.com/tags/weather-station/" />
<published>2023-04-29T17:47:00Z</published></entry>
<title><![CDATA[Planning PWS Hardware]]></title>
<link rel="alternate" type="text/gemini" hreflang="" href="gemini://benjaminja.com/log/2023/04/16-planning_pws_hardware/" />
<id>gemini://benjaminja.com/log/2023/04/16-planning_pws_hardware/</id>
<updated>2023-04-16T17:26:00Z</updated>
<summary type="gemini"><![CDATA[It has been a dream of mine to create my own personal weather station (PWS). I’ve been working on this project for over 6 years now. Due to school and scope creep: I have not been able to complete this project.
]]><![CDATA[It has been a dream of mine to create my own personal weather station (PWS). I’ve been working on this project for over 6 years now. Due to school and scope creep: I have not been able to complete this project. This time will be different. I have a plan. This plan has been split up into two parts: hardware and software. In previous iterations, I have developed hardware and software at the same time without a clear plan, which I believe is part of the reason why it has taken me so long.
With this semester is almost over, I have done a bit of planning so I can hit the ground running with this project. I want to have the hardware installed as soon as reasonably possible so that I can start work on the software remotely.
The general idea for this project is to have a weather station that hosts a web-app. This would allow you to view the current weather conditions from anywhere in the building.
In order to do this, I will have a raspberry pi to host the server and communicate with the station hardware. The station hardware will include a weather vane, rain meter, temperature, humidity, pressure, and possibly a uv-index sensor. This will all be directly controlled by a teensy.
The raspberry pi will sit on the roof in a shady spot. It will be connected to the internet via ethernet and get power over ethernet (PoE). The pi will interface with the teensy using CAN over an ethernet cable. It’s possible that the pi could be placed indoors, but I want to attach a camera as a little bonus thing. The teensy will be directly connected with all the sensors over i2c. The weather vane and rain meter don’t have any logic chips and so will need to be specially programmed.
The teensy will generally act as a bridge between the sensors and the pi. The weather vane and rain meter will need special logic which I will go into later. The teensy will respond to requests from the pi. The pi will run OctoWeather (PWS software that I am developing). I haven’t made any plans yet of how this software will work, but I have general ideas of what it will do in my projects page.
The weather vane has two parts: wind direction and wind speed. Both of these use reed switches to detect what is happening. The wind speed closes the circuit on every rotation (maybe every 180º I can’t quite remember which). The wind direction has eight reed switches each connected to a different resistance to detect which cardinal direction the wind is blowing in. The rain meter has one reed switch that triggers every time 0.01 inches has fallen. The wind speed and rain meter will need to have special software to asynchronously determine how much rain has fallen and how fast the wind is blowing. This should be relatively easy by using pin change interrupts. The wind direction can be connected to a voltage divider to measure resistance on an analog pin.
I have been able to install an ethernet cable that goes from the basement to the roof. I have also collected all of the hardware that I plan to use for this project.
=> 🖼 Ethernet Going to the roof
=> 📭 Message me | 📝Or mention this post
]]>
<category term="projects" label="Projects" scheme="gemini://benjaminja.com/tags/projects/" />
<category term="weather-station" label="Weather-Station" scheme="gemini://benjaminja.com/tags/weather-station/" />
<published>2023-04-16T17:26:00Z</published></entry>
<title><![CDATA[Weatherstation: Charging Circuit]]></title>
<link rel="alternate" type="text/gemini" hreflang="" href="gemini://benjaminja.com/log/2018/05/24-weatherstation-charging-circuit/" />
<id>gemini://benjaminja.com/log/2018/05/24-weatherstation-charging-circuit/</id>
<updated>2018-05-24T23:19:17Z</updated>
<summary type="gemini"><![CDATA[One of the big things on the to-do list is a charging circuit. I need a charging circuit to allow the solar panel to charge the battery. Lucky for me, the Arduino Feather 32u4 has a built-in charging circuit, but then why would I need a charging circuit?
]]><![CDATA[One of the big things on the to-do list is a charging circuit. I need a charging circuit to allow the solar panel to charge the battery. Lucky for me, the Arduino Feather 32u4 has a built-in charging circuit, but then why would I need a charging circuit?
I bought a little voltage regulator for the solar panel which makes sure that the voltage stays at 5V. If the voltage goes below 5V and has enough current, then the output voltage will be 5V with a little less current. I’ve done this because the charging circuit does not work with lower than 5V. After some testing, I found that the built-in charging circuit stops charging the battery if the solar panel goes through the process of losing sunlight, then regaining the sunlight. In order to fix the issue, I can disconnect the power line from the solar panel to the device when there is no sun. So the charging circuit isn’t actually a charging circuit, but rather a charging enable circuit.
My original design used an N-MOSFET. I used an N-MOSFET because everyone uses NPN BJT transistors, so why not use an N-MOSFET. After learning about MOSFETs, I created my V1 charging circuit. It had a voltage divider to probe if the solar panel was getting any sun or not. The circuit with the N-MOSFET had to be connected to the solar panel’s ground: The drain pin should be connected to the load, and N-MOSFETs drain should be more positive than the source (See below image for more detail).
The only problem as you might have guessed is that I could not check the voltage of the solar panel without the N-MOSFET enabled, because the ground was being disconnected, and so the measured voltage had no reference.
I couldn’t find the schematic, or picture of the original circuit.
After a few months of ignoring the enable circuit, I decided to work on it again. After learning a bit more about P-MOSFETs, I found that the only difference between them is the voltage of the source and drain. The P-MOSFETs drain should be more negative than the source, so the MOSFET should be placed between V+ and your load.
=> StackExchange - Basic p type MOSFET question
After some experimenting with the new circuit on a breadboard, I found that I don’t need the voltage regulator. In fact, the voltage regulator was causing all the problems that made me design the charge enable circuit. I don’t need the voltage regulator, because the solar panel is a 5V panel, and won’t be able to produce enough current to step the voltage up if it isn’t even at 5V.
Just because the solar panel now charges the Feather doesn’t mean that creating a new charge enable circuit isn’t useful. If the temperature is too cold or too hot, I shouldn’t allow the Li-ion battery to be charged–The temperature range for Li-ion batteries are [32F to 113F]. I don’t know how I will insulate the battery to help prevent reaching those temperature ranges, but that is a problem for another day.
=> 32F to 113F
=> 📭 Message me | 📝Or mention this post
]]>
<category term="wordpress" label="Wordpress" scheme="gemini://benjaminja.com/tags/wordpress/" />
<category term="weather-station" label="Weather-Station" scheme="gemini://benjaminja.com/tags/weather-station/" />
<published>2018-05-24T23:19:17Z</published></entry>
<title><![CDATA[Weatherstation: Lots Happening]]></title>
<link rel="alternate" type="text/gemini" hreflang="" href="gemini://benjaminja.com/log/2018/05/18-weatherstation_lots_happening/" />
<id>gemini://benjaminja.com/log/2018/05/18-weatherstation_lots_happening/</id>
<updated>2018-05-18T18:21:09Z</updated>
<summary type="gemini"><![CDATA[Starting in April, I have started working on the weather station project again, and I have failed to make any updates since. So I’m going to try to write everything I have done in this past month and a half.
]]><![CDATA[Starting in April, I have started working on the weather station project again, and I have failed to make any updates since. So I’m going to try to write everything I have done in this past month and a half.
First, I created a new repository for the project on [Github]. In this, I have migrated my weather station from an Arduino project to a [PlatformIO] project. This is significant since the Arduino editor works only as a text editor and compiler, while PlatformIO on VSCode acts as a full IDE with code completion along with support for the old Arduino libraries.
=> Github | PlatformIO
Rather than waiting for commands, the weather station waits for 30 seconds then turns on the radio, and sends the weather packet. This is done for power saving. Before, the weather station had the radio turned on and listening 100% of the time. This wasted a relatively large amount of power.
The weather station now accepts commands after sending the weather update: Set Value, Get Value, Set EEPROM, Load EEPROM, Get Status, and Reset. These commands can be bunched together in packets. Some commands send replies which are sent in order after all the commands are sent.
The base station is the raspberry pi device that receives the raw weather data from the weather station through the rf24 chip. It receives the weather, processes the data into human-readable units, then uploads the data to Weather Underground. Most of the work done this past month is for the base station.
I have done a little bit of work in the past on the base station, but very limited. Then I planned to have the program run primarily in python, running a c++ script to get the weather from the radio chip. Now, most of the work done is in a C++ program, running a python script that uploads the weather to [wunderground.com].
Program Loop
It runs in a 30-second loop that is synchronized with the weather station. To get synchronized, it will leave the radio on and wait until a transmission is received before beginning the loop again. One problem I found with this system is that the Arduino and raspberry pi clocks aren’t the same. Even though they both wait 30 seconds, one seems to be slightly faster than the other. The problem is solved—too complicated to explain—by the following code snippet.
//wait for an available packet
time_point t = Clock::now();
while(!successfull && timeDiff(t, Clock::now()) < eeprom::listenTime) {
sleep_for(500ms);
successfull = checkForPacket();
count++;
}
//If we are desyncing, compensate.
count -= (eeprom::listenTime /500) /2;
if(count !=0) {
reloadTime += (count *500);
cout <<"Desynced by "<< count *500<<"ms, adjusting"<< endl;
}Every time the weather station successfully sends a packet: the program will process the data. Upload the weather. And send any commands. Since I have a website to check the current weather/station status; I need to have some way of getting that data to the website. So I decided to use MySQL for data storage and transfer.
MySQL
I am not very skilled in MySQL; after all, I’ve only just learned it. My plan for the database is to hold the weather for 24 hours to display on the website and to move information from one program to another without the hassle of parsing individual files. Here are the tables I have made, displayed in a table.
Website
The website I’m making is designed to be for me only: to get information about the station without SSHing into the baseStation. If I wanted to get the weather, I would use Weather Underground. Also, I don’t think a Raspberry Pi Zero is equipped to handle more traffic than my immediate family.
The website is fairly straightforward, I’m using the [SB Admin] Bootstrap template. A few pages: One displaying the status, and other useful information. Another with the current weather with a 24-hour graph of previous temperatures, pressure, humidity, rain, and wind. I’m using PHP to connect to the MySQL database to get the weather/status information.
=> SB Admin
In the future, I want to have a page for configuring the weather station from the website. Such as setting EEPROM variables on the weatherStation, or resetting the system remotely. One worry I have is permissions. I want the website unable to process these commands unless I am logged in. However I have never done anything like that before, so could be more difficult than I think. Of course, it could also be much easier than I think as well.
As I continue to work on this project, I want to post once a week, or whenever I work on the weatherStation. That way I could give more detail, and include more code snippets to help anyone who might find this website who is also building their own weather station. I hope to get this project done in the next month; I also was planning to get it done a year ago so don’t expect too much.
=> 📭 Message me | 📝Or mention this post
]]>
<category term="wordpress" label="Wordpress" scheme="gemini://benjaminja.com/tags/wordpress/" />
<category term="weather-station" label="Weather-Station" scheme="gemini://benjaminja.com/tags/weather-station/" />
<published>2018-05-18T18:21:09Z</published></entry>
<title><![CDATA[WeatherStation]]></title>
<link rel="alternate" type="text/gemini" hreflang="" href="gemini://benjaminja.com/log/2018/04/09-weatherstation/" />
<id>gemini://benjaminja.com/log/2018/04/09-weatherstation/</id>
<updated>2018-04-09T18:12:09Z</updated>
<summary type="gemini"><![CDATA[🐙 GitHub Repository 📓 WeatherStation Posts This is an ongoing project, see the above links for more information on the project A number of years ago, my father got a home weather station for his birthday.
]]><![CDATA[=> https://github.com/ttocsneb/Weather-Station 🐙 GitHub Repository
This is an ongoing project, see the above links for more information on the project
A number of years ago, my father got a home weather station for his birthday. It is a simple station that reads wind, rain, temperature, and humidity. It was a good for seeing how much rain we got, or how hot it is at our house. Somewhat recently, it broke, we aren’t sure what happened, but I decided to recycle the parts and create a new, better weather station.
My plan is to make a weather station that uploads its data to [wunderground.com] using their [PWS Upload Protocol]. The problem is that I need to send the weather data through a GET request, which I need a device with wifi. I could use an Arduino with wifi, but I don’t think that our wifi has a good enough range to use from the roof. So I am using an [RF24L01+] module from the station to a raspberry pi 0 base station, which will upload the data.
=> wunderground.com | PWS Upload Protocol | RF24L01+
The idea is simple but has a number of problems that need to be addressed, such as power. I plan to use a Li-ion battery with a solar panel to charge.
Every 30 seconds, the station will activate the radio, and send the weather data down to the base station, then listen for any commands for the next 2 seconds. This will allow me to make changes to some constants in the station without having to reflash. I should also be able to ask the station to do things, such as reset.
The commands are single chars followed by whatever else is needed. ie ‘S’ is for setting the value of a constant, followed by a char of the code for the constant to be changed, followed by the value. If the command is a request, the station will send a packet back to the base.
I am using an Adafruit Feather chip which has a Li-ion charging circuit built-in, so all I need to do is connect a solar panel to the charger. However, I ran into an issue, where when the power drops too low to charge, then rises back, the charging circuit will stop charging as expected, but will not start charging again until the solar panel is disconnected and reconnected. I plan to create a circuit with a mosfet and voltage reader so that the station can deactivate the solar panel when it can’t supply enough current.
=> 📭 Message me | 📝Or mention this post
]]>
<category term="wordpress" label="Wordpress" scheme="gemini://benjaminja.com/tags/wordpress/" />
<category term="weather-station" label="Weather-Station" scheme="gemini://benjaminja.com/tags/weather-station/" />
<published>2018-04-09T18:12:09Z</published></entry>
<title><![CDATA[Weatherstation: Software]]></title>
<link rel="alternate" type="text/gemini" hreflang="" href="gemini://benjaminja.com/log/2017/06/17-weatherstation_software/" />
<id>gemini://benjaminja.com/log/2017/06/17-weatherstation_software/</id>
<updated>2017-06-17T21:27:42Z</updated>
<summary type="gemini"><![CDATA[I finished wiring the station, though I would not be surprised if I need to make some last minute adjustments. The last bit of wiring I have done is interfacing with the existing hardware. The rain gauge and anemometer connect directly to the board with an internal pull-up activated.
]]><![CDATA[I finished wiring the station, though I would not be surprised if I need to make some last minute adjustments. The last bit of wiring I have done is interfacing with the existing hardware. The rain gauge and anemometer connect directly to the board with an internal pull-up activated. The language is connected to D11 for PCINT7 which allows for interrupts. The weather vane is connected to A0 through a 5k7 resistor to act as a voltage divider with the resistors in the weather vain as the second resistor. The solar panel connects to the USB pin through a step-up converter to make sure there is a 5V output.
=> 🖼 wiring
As for the software, I created a simple flowchart of what the station will do.
=> 🖼 flowchart
The Program will wait for commands, I expect to update once every 30 seconds. It will then process the command, then repeat. It is a very simple system. though will be slightly more complex than that.
I haven’t programmed the commands yet, rather got or getting the processes ready to be commanded. So far have had weatherdump mostly finished, as well as settingdump. They are not yet functional enough to be plugged into a communications API, but the framework is there.
WeatherDump
The weatherdump sends back all of the weather data from about the time the dump was requested. It should start out collecting the wind data as that takes at least 2 seconds. Everything else reads fairly quickly. Next is the weather vain, which just finds which of the eight reed switches are closed. The temperature and humidity come from the DHT22, and pressure comes from the MPL115. The grain count is stored in a variable that may or may not reset after each reading(I haven’t decided yet)
SettingDump
All of the settings are stored in the internal EEPROM. The settings are fairly simple, just conversions or other various settings regarding weather data. I am doing this so that if I find an error with my system, I can easily fix the small issues without having to take down the weather station and reflash it. I am mainly storing Integers, doubles, and booleans. As EEPROM stores its values as bytes and has no conversion systems, I have created a few converters. The first converter simplifies the booleans into bytes to conserve memory. The second converts Integers into two bytes. The third converts doubles into 5 bytes. It starts out by finding out how many bits the double needs to become a long. After that, the long is turned into 2 ints which are then saved using the previous writeInt command. The last 5th byte stores the number of bits the double is compressed by.
=> 📭 Message me | 📝Or mention this post
]]>
<category term="wordpress" label="Wordpress" scheme="gemini://benjaminja.com/tags/wordpress/" />
<category term="weather-station" label="Weather-Station" scheme="gemini://benjaminja.com/tags/weather-station/" />
<published>2017-06-17T21:27:42Z</published></entry>
<title><![CDATA[Weather Station Part 2]]></title>
<link rel="alternate" type="text/gemini" hreflang="" href="gemini://benjaminja.com/log/2017/04/15-weatherstation_part2/" />
<id>gemini://benjaminja.com/log/2017/04/15-weatherstation_part2/</id>
<updated>2017-04-15T21:11:33Z</updated>
<summary type="gemini"><![CDATA[I have started working on the main board for the station. Adding the transceiver, barometer, temperature, and humidity sensor. It is going pretty well so far. I have not yet tested the rf24 module, though the two other modules I have confirmed to work.
]]><![CDATA[I have started working on the main board for the station. Adding the transceiver, barometer, temperature, and humidity sensor. It is going pretty well so far. I have not yet tested the rf24 module, though the two other modules I have confirmed to work. The MPL115 works pretty well and seems to give good readings, though I can’t really test it without putting it in a vacuum chamber or climb a mountain, which is fairly difficult, let alone try to tether it to a computer. The humidity sensor reads humid in my mouth, and the temperature sensor senses the proper temperature.
=> 🖼 chip_top
I was also able to do some testing on the old equipment. Most of it worked how I expected it would, though with a little twist. I started with the wind meter.
The wind meter will be the easiest to implement. It has a single switch that pulses every 180°. The switch closed most of the time except for when pulsing, which opens the circuit. It will be really easy to implement as I only need to find the amount of time between two pulses. The hard part will be finding the conversion rate between rpm and airspeed. I wouldn’t be surprised if the information is readily online, but if it is not, I can take a few readings in a car ride at a set speed in a no wind environment.
Next is the Rain Gage. It is fairly simple, though it will be a bit harder to implement. The Rain gauge collects water in a see-saw thing. the water goes to one side until its bucket fills up and rocks the see-saw to the other side. This process repeats, but on the other side. when the bucket falls, the switch is pulsed. To implement, you just have to keep track of how many times the bucket dropped. It is really simple in principle, though in practice will require the system to always be listening for the switch to switch. An interrupt should do the trick. As for conversions, I believe each bucket drop is 0.01in, as that was the increment of the station before it broke, but I will have to confirm; Probably by leaving it out on a rainy day with rain bucket as a base.
The last is the weather vain, arguably the most difficult to implement. There are eight switches, one for each direction. each switch is parallel to each other with a different resistor paired with each. The resistor’s value seems to be random, making it more difficult to implement, though not by much. To implement, I would use a 100k5k7 pull-down resistor to get the following table. Though what I found interesting is that my readings from the last post are different to what the calculated resistance is.
I am certain that I am wrong about the resistance, either in my calculations, or my setup, but I remember reading the resistance on my meter to be correct.
It turns out that I took out the resistor from a different box then what I thought I did for the pull-down resistor, it is actually a 5k7 resistor. Everything works out as it should though the West direction should read 4.254V instead of the actual 0V. I believe that a connection is somehow broken, but should work out fine in the final setup.
=> 📭 Message me | 📝Or mention this post
]]>
<category term="wordpress" label="Wordpress" scheme="gemini://benjaminja.com/tags/wordpress/" />
<category term="weather-station" label="Weather-Station" scheme="gemini://benjaminja.com/tags/weather-station/" />
<published>2017-04-15T21:11:33Z</published></entry>
<title><![CDATA[Weather Station]]></title>
<link rel="alternate" type="text/gemini" hreflang="" href="gemini://benjaminja.com/log/2017/04/04-weatherstation/" />
<id>gemini://benjaminja.com/log/2017/04/04-weatherstation/</id>
<updated>2017-04-04T21:03:54Z</updated>
<summary type="gemini"><![CDATA[I am starting a weather station project, taking an old broken weather station, and getting it to work with Arduino and a Raspberry Pi web server. After a quick inspection of the ports on the old station transmitter, I found that the weather vain uses a 4 wire plug.
]]><![CDATA[I am starting a weather station project, taking an old broken weather station, and getting it to work with Arduino and a Raspberry Pi web server. After a quick inspection of the ports on the old station transmitter, I found that the weather vain uses a 4 wire plug. This got me worried as the colors also matched the i2c wire colors. After opening the vain, I found no ICs of any kind in the chip.
The board uses two of the four wires, and the other two are relayed from the wind speed device. the vain uses 8 reed switches, each connected from P4 to P1 through a resistor (each switch has a different resistance).
The placement of the resistors seem random, and I don’t know how I would find which switch is active, as I don’t think it is possible to find resistance solely from voltage difference. I’ll have to do some more testing.
=> 🖼 chip
I found that the anemometer also uses reed switches, one to be exact. It seems to switch states every 180°. It seems like it will be the easiest part to implement, though I will have to figure out a conversion between rpm and windspeed.
I haven’t yet opened it up, however I can tell that it uses a reed switch. When water enters the device, it will fall into a trough. When the trough fills, It will tip over emptying the water changing the state of the reed switch. Another trough on the other side is now collecting water continueing the cycle.
I think that each switch is equivelent to 0.01in though I’ll have to do some testing to be sure.
=> 📭 Message me | 📝Or mention this post
]]>
<category term="wordpress" label="Wordpress" scheme="gemini://benjaminja.com/tags/wordpress/" />
<category term="weather-station" label="Weather-Station" scheme="gemini://benjaminja.com/tags/weather-station/" />
<published>2017-04-04T21:03:54Z</published></entry>
text/xmlThis content has been proxied by September (ba2dc).