I like the Firefox "New Tab" page. But sometimes it picks stale thumbnails (like, the login page and not the real page) and keeps them around forever. If you open up Scratchpad and set the Browser execution environment, focus a tab on the page whose icon is stale, and run:
I've been continuing to set up my new 3D printer, after first assembling it last weekend. This is the first object that I could call successful. After lots of time spent in calibration for the height I went back and checked the diagonal arms which were indeed not all the same length and fixed that last night. Today I tried a couple prints which completely failed to stick to the build plate. A layer of blue painters' tape completely fixed that! This particular test object seemed to stop extruding partially through the top layer, but it's close enough, so I'm calling it my first success!
Besides modding my phone yesterday morning, the vast majority of the day yesterday and today has been spent on assembling my new 3D printer. I've been down on 3D printing overall for some time, largely due to quality issues and the amount of time that it takes to complete a print. I've got access to a 3D printer at work, which has satisfied me for occasional small projects over time. But I just completed a big one. And more importantly, for this post, I also got lucky and snagged roughly 40 one kilogram rolls of free ABS filament recently. For free.
That was enough to push me over the edge and get my own. Forty kg is effectively a lifetime supply. The big project I mentioned took over twelve hours to squirt well under half of a kilogram of filament into my custom shape. I could make 160 of those with this much filament.
Anyway, above is a set of pictures showing all the parts. I got a kit, because not only are kits cheaper, I enjoy putting them together. Plus, it means I know for sure how it all goes together, which helps inform knowing how it works, which makes repairs down the line easier. I've just now completed the last major part of assembly. All the screws are screwed in, all the wires are plugged in. I've turned it on and done the most basic of things (move a bit, go to auto home), and those basic things work.
Here it is in all its glory. You might notice that this is not a traditional ("cartesian") 3D printer. Instead it's a "delta" style, which moves three arms up and down; when moved properly in concert the print head they connect to in the middle can be made to move left/right, forward/back, and up/down. But all the motors doing this are fixed, at the base, driving the arms through belts. So there's less mass to move around, which is always a good thing. Specifically this is a Geeetech G2s Pro. Which in addition to being a delta, which I like, also has two extruders. Meaning in theory (if I can learn how...) it can print with two different filaments, like two different colors, at once. Which presents exciting opportunities.
There's still a ton of things to check. All the wires are plugged in, but are they plugged in correctly? To the right thing? Does it get hot when I ask? Does it squirt out plastic when I ask? Is it level and square in each of the several ways that it needs to be? Are the fans pointing in the right direction? Do any of the wires or tubes bind up when the print head moves around?
So this is not "project done". But it's a significant milestone.
A while ago I decided that I'd wait until near the end of the year and seriously consider opening up my Nexus 5X. First, to replace the nearly year old battery and second to modify it for wireless charging. I completed that work today. This first picture shows the phone opened up. The iFixit guide for battery replacement was very useful. With the right tools, as pictured (except the #000 phillips driver), it was quite straightforward to get inside. It's worth noting that the metallic sticker, still in place as pictured, on the inside of the back cover must be removed, so the electric field can get inside to the coil!
Here's a close up image of the completed modification. I used the +5V point on a capacitor as pointed out on YouTube, but for ground just used the nice big USB-C connector shield, which I verified was also grounded. Some thin gauge wire-wrapping wire is small enough to not get in the way of anything. Since the wires are only around an inch long, I'm not concerned about the resistance of thin wires.
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!)
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.
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.
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.