💾 Archived View for jdcard.com › LagrangeKiller › 16-weatherstation-update.gmi captured on 2024-05-26 at 15:18:03. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
2024-05-16
đź–Ľ 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.
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:
1. The teensy is generating too much heat, affecting the readings.
2. The Direct sunlight is increasing the temperature of the enclosure even though it is well ventilated.
3. Waterproofing the chip could have caused problems with the sensor. (I did not waterproof the sensor itself, just around it, but I could have made a mistake)
4. The sensor is faulty. I could just be unlucky and got a chip that wasn’t well calibrated.
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.
