2016-08-06 11:23 - Making
My new boards arrived and I've assembled the first (totally working!) "wi_ther" environmental sensor. The prototype, which I've posted about before, and was supposed to be the final version, is on the left while the new board is on the right.
The new board is larger, to put more space between the hot WiFi/controller chip and the three sensors, which are closer to the proper USB connector, rather than the on-PCB fingers. I got the connector a tiny bit wrong, I had to cut off a bit of the board to make it fit properly, since I put too much empty space around the holes for it to mount to.
You can see three internal cut out slots to help break any thermal transfer from the controller to the part of the board where the sensors are. The surface mount temperature sensor also has extra cutouts around it, and the two other sensors have big slots cut out beneath them, which is nearly invisible in this picture.
I'm still finalizing how I want the software to work. For now this system is running an HTTP server, which can be polled. I've also considered letting it run as an HTTP client, periodically pushing the data out. It might be nicest for it to run as an independent system, keeping a buffer of historical data in memory, in case anything causes my normal system to miss then that data can be retrieved thanks to the independent storage. But for now, it's time to stress test it and verify whether my thermal design for this version helps the sensors provide accurate data. (Early signs are good! In the few minutes it's taken me to type up this post, the reading has remained flat, so they haven't been heated by the processor!)
2016-08-04 23:18 - Gaming
I've just completed the final battle in Super Mario RPG, and saved the kingdom from the evil Smithy.
2016-07-20 21:17 - Making
Here's a picture of the just completed first prototype for my wireless weather sensor. I'm upgrading the temperature sensor design because I didn't do a great job with it. I got it to the point that it's barely functional, learned some things, and so now it's time for round two.
I've still got the DS75 temperature sensor I started with. It's at the top middle of the picture, the tiny chip on the larger green board. Moving slightly counterclockwise, behind a forest of wires, is a black box: that's an AM2320 sensor which does both temperature and humidity. Continuing clockwise from there on a purple breakout board is a BMP280 barometric pressure sensor, which also does temperature to boot.
All three of these chips speak the same I2C communication protocol, so it's just the two orange wires from the big board at the bottom (a clone NodeMCU) that connects to all of them, as I2C is a shared bus. Now that I've got it working, I know for certain that I understand all three chips and how to wire them up. And get data out:
Reading at 874742: AMT=80.06; AMH=49.00; BMT=82.83; BMP=101974.61; DST=81.05
They only mostly agree about the temperature, with a drift of a couple degrees between them. In practice I'll probably take the average (mean) of all three readings. I've got plans for a PCB to put all this on. It will be bigger than the previous one, and more carefully designed, with internal slots to make sure the heat from the WiFi/controller chip doesn't reach out to foul the temperature sensors' readings, and a real USB connector (just for power) rather than trying to use the PCB itself for that when it's too thin to do that job well.
2016-06-29 23:50 - Making
I've "finished" my wireless temperature sensor project. At least the first version.
The first picture here is the final test before "done", on a breadboard. It's assembled and plugged in there. Look at the middle picture and you can just see (U4) the first mistake. The power regulator isn't the size I thought it was. I got lucky that I could force the smaller chip to line up just good enough to use anyway. Then on the breadboard I realized the second design mistake. I knew of the idea of designing thermal relief into a board like this, with temperature sensor included. I neglected to do so, however. Turns out the chip running the WiFi pushes the temperature on the board up around ten degrees above ambient, and with the (surface mount) temperature sensor (U3, top right of the mostly-in-focus middle picture) also right on that board, under an inch away, it doesn't give the sort of readings I want.
Luckily the next day the pair of AM2302 sensors I ordered arrived in the mail. These are the same as the DHT22, which is compatible with the DHT11. I've had some DHT11 units for a while — they're awful quality (for this application), but they do have a passable humidity sensor. And I had nothing else to do with them, so I left a place to put one in. The DHT22/AM2302 sensors are much better for this project. And they're not surface mount, so they won't be corrupted (as much?) by the heat of the processor/WiFi work. It's the white plastic box visible in all three pictures (most obviously in the last one).
The new sensor was pretty easy to hook up to the dev board (bottom right of the first picture), which is a cheap NodeMcu knockoff. But I couldn't get it to work in my board. Turns out I selected an arbitrary pin (11, GPIO9) based on proximity/convenience on the board. That pin won't work for this application (argh!), and I didn't test that before getting the board made. So, as you can just see in the last picture, the data pin is lifted, extended, and run over to one of the extra GPIO breakout points I included "just in case" (phew!) which works.
So far it's been plugged in since last night and it's happily answering my queries for data. I'm running a quick test to see what sort of data it produces overnight. But overall, it looks to be in a good enough state to begin using.
This is my first ESP8266 project, to mixed results. It's really convenient to have a programmable WiFi capable microcontroller, but programming is a bit of a pain, all the networking smarts bulk up the programs a lot, so they take a while to upload. Plus it's a bit of a dance to get it in the right mode to accept the programming. For my board, I ended up relying on the second UART port for diagnostic output, I couldn't get reliable data out of the primary one. If I have another small project where WiFi interaction would be useful, I'll probably give it another try but I'll be cautious.
That second project might be a second version of this very project. I'd like more sensors so I could know, for example, how much (if any) difference there is in temperature in various parts of my apartment, especially "upstairs" in the sleeping loft. That's why I made it wireless: so it's easy to put wherever I want, as long as I have power available to run it. I can fix the mistakes I know of, and perhaps try again with a new better version.
2016-06-21 21:54 - Linux
I've been tweaking the setup of my home network recently, related to the building of my WiFi enabled temperature sensors. Two options for letting them exist in a self-sustaining way are mDNS and SSDP. I think I have mDNS working but I also wanted to try SSDP. After much looking I found that smcroute ("a command line tool to manipulate the multicast routes in the UNIX kernel") seemed to be what I needed.
But I'm running a quite old version of (a variant, actually, of) OpenWRT. I couldn't find a binary package that worked, so I built my own. I had to try several times before I got it to work. It was actually a linking error; the default instructions build much newer, incompatible, things than what I can use. But being a tiny embedded style system, when I built a "bad" binary and ran it, I'd only get "-ash: ./usr/sbin/smcroute: not found" even though the file was definitely there. Its dynamic library is what was missing!
On the off chance that somebody on the interwebs will find it useful, here's smcroute_2.0.0-1_ar71xx.ipk built for MIPS (Atheros AR71xx) and uClibc.
2016-06-05 18:37 - Making
I've had computerized logging of temperature, indoor and outdoor, since I lived in my previous apartment. Both the heat and A/C there was electric, which I paid for. With a clunky old unit. So I hooked temperature sensors to the server I ran all day anyway, and put a relay in front of the HVAC unit to create a simple thermostat. It's fun information to have, so I've kept it.
But they sensors are clunky wired units with some nasty quirks; for example on Friday it said the temperature inside remained exactly 77.1 degrees for about 20 hours straight. There are a couple spots that it will get "stuck" like that, and it limits the possibilities for me to lay things out (server + wire must reach out the window to keep outdoor data).
I've meant for quite some time to build something better. I have an esp8266 wireless unit bought on impulse lying around, at bottom left of the image besides this text. I've also got some DHT11 sensors I could hook up to it. Those are the little blue boxes in the top right, three in the tray they came in and one actively hooked up. And working!
But the DHT11 turns out to be awful. It only gives 1 degree Celsius resolution, so about two degrees Fahrenheit; I'd prefer something like 0.1 degree F resolution. It also does humidity which is nice, but with similarly lackluster abilities.
In my last electronics parts order I grabbed a few DS75 chips, which can do temperature to 0.0625°C resolution. It's sitting on the green board in the bottom right of the picture; next thing to do is to try to talk to it!
Update, on the 6th: I've got the DS75 hooked up and working and I can indeed get my 0.1°F or so readings out of it. I know for sure because I can watch it heat up a bit as I touch it with my finger, and cool off when I let go.
2016-05-16 21:19 - Making
I recently became the proud owner of a Raspberry Pi Zero. An amazing little gadget for its $5 price point! But as a result the features are a bit spare. When I found this RPi WiFi project on Hackaday I was hooked, I needed to have one. But it's not available, yet.
The original project is more ambitious than my adaptation of it. I only put the ESP module and a breakout for (power and) serial data. A stacking header mates with male header pins attached to the Zero, and voila! The original seemed to be called "WiFi Pants", with my simpler version intended to work with the Pi Zero, I chose to call mine "Zero Pants".
There's just one caveat: it doesn't start at boot. I'm pretty confident this is because I'm using the ESP-12-E module, which is set up with embedded flash and program to run. So I have to do the GPIO twiddle in step 10 of the instructions. But that causes a kernel panic. Actually what I need to do, so I have for now as a script file, is:
#!/bin/sh
rmmod esp8089
echo 0 > /sys/class/gpio/export
echo low > /sys/class/gpio/gpio0/direction
echo in > /sys/class/gpio/gpio0/direction
Remove the kernel module first, then toggle the GPIO pin to cause the ESP to restart. The module automatically reloads itself, and if you have a valid wpa_supplicant.conf set up, it connects in just a few moments.
Plus I needed to patch the esp8089 module to get it to compile for the recent kernel I got by following the instructions. (As mentioned in the comments.) But hey, it was a nice fun small project!
I ended up not installing either of the LEDs in this, the second module that I assembled. I got something wrong so the power LED was unnecessarily bright, and the "init" LED did indeed blink correctly to let me know the GPIO was twiddled. But it's normally high, so stays on the whole time, and also terribly dim, because it's being powered through the (I assume?) processor's internal pullup resistor. So no need to keep that!
2016-05-08 16:39 - Making
After quite a delay I'm continuing this series of posts.
I've learned that Samsung's SAM8 line of microcontrollers is based on the Zilog Z8:
Historically, the SAM8 and SAM88 CPUs that are the core of the S3 Family were based on Zilog’s efficient Z8 architecture. For Zilog to introduce the S3 Family is simply a natural evolution culminating in a cooperative agreement between IXYS and Samsung.
And that Zilog has purchased this line from Samsung to bring the product full circle:
IXYS Corporation, parent company of legacy and legendary microcontroller manufacturer Zilog, has entered into an agreement to purchase 4-bit and 8-bit Flash microcontroller product lines from South Korean semiconductor manufacturer Samsung Electronics for $50 Million.
This nugget of info helped me find the S3 Embedded Flash Serial Programming document (mirrored at archive.org and locally), which at first seemed very promising. The best I could find from the datasheet was vague references to "tool mode" which the TEST pin could set, but not whether it's active high or low, and also a NRESET pin with no polarity/value indication, and SDAT/SCLK which sounds like I2C. (The N in NRESET implies active low, and some vague wording implies active high for TEST, but that's not enough to go on by itself.) And no data about the protocol. But this S3 document from Zilog mentions pins with nearly identical names, has much more clear wording about the Reset and Test pins, and specifies the protocol to talk over the data line!
Unfortunately all my attempts to whip up something to talk to this chip with that protocol have failed. The Arduino is terribly easy to work with, but I've only got 5V modules, so I tried working with the 3V STM32 board I have instead. I might have been tripped up by the dual-direction data line (output at first to specify the operation, then input). Either way, I can't get the chip to respond.
Next up is the J6 header which just has two power pins and two UART interfaces. It took a little digging, but I found that UART1 spits out some data at power up, at 38400 N81; here's several repetitions:
00000000 00 00 55 49 42 30 01 0b 00 00 55 49 42 30 01 18 |..UIB0....UIB0..|
00000010 00 00 00 55 49 42 30 01 0b 00 00 55 49 42 30 01 |...UIB0....UIB0.|
00000020 18 00 00 00 55 49 42 30 01 0b 00 00 55 49 42 30 |....UIB0....UIB0|
By watching in my logic analyzer, I can see an 0x00, followed by an 8ms delay, then the 0x00 UIB0 0x01 0x0b, a 10ms delay, an 0x00, another 8ms delay, then the 0x00 UIB0 0x01 0x18. There's a clear pattern here, but I can't interpret the data. With the guts of the remote tacked down to the breadboard I can hardly interact with it. When I move it the backlight lights up, but I see no serial traffic. I can get to a few of the hard buttons beside the display, and they also have no effect.
The JTAG interface remains. But it will remain a topic for another day, as I've got learning to do before I have a chance of making progress.
2016-04-23 14:20 - General
I went out for lunch today, and chanced upon a street fair. One of the booths was selling framed art and I picked up Spiderman and the twin towers for only $10 each. After hanging them, my wall is getting pretty close to full!
