It all started a few years ago, when I saw an Inspector Lewis episode that included a person who was giving totally-false walking tours of Oxford, talking about alligators in the river and such. I was enchanted by the idea of a Walking Tour as a work of fiction. After a little research I found 230 Miles of Love, a comedic audio tour that you download to your car navigation system and enjoy as you drive the M6 in the UK.

Meanwhile, on our travels over the years, Linda and I have experienced countless walking tours of Cathedrals, castles, ancient town walls, etc. One day it struck me: what would a historical walking tour in the next century, of a town near our home look like? What would a reenactment such as Colonial Williamsburg look like to an 18th century resident of Williamsburg?

I created the walking tour to run like 230 Miles of Love, where each track would be triggered by the listener entering a new location in the tour. Unfortunately, I haven’t found a platform I can put this tour on, so the audio languished for years.

Last week I found my new vehicle: YouTube, via ShotCut. ShotCut is an Open Source, cross-platform video editor that’s easy to use, yet fully featured. It took me less than a day to learn what I needed of ShotCut and to assemble my audio tracks and photos into a video.

So I’ve converted my walking tour into a talking slide show, to give you a rough idea of what the walking tour would feel like as you walk around downtown Hillsboro. Enjoy.

Having recently finished reading Clifford Smyth’s excellent book, Functional Design for 3D Printing, I was anxious to try out his method of cutting a design into parts and gluing those parts together after printing. One big point he made in his book is that (additive) 3D printed designs are far stronger in the XY plane than in the Z direction, and so it’s often best to print a design “sideways”, as separate parts that you glue together with Super Glue. He points out that fastening parts together with Super Glue takes only seconds, while removing support structures after printing can take a while (and can be a pain).

So I created a simple little stand for paper cups, to sit by the bathrooom sink. It’s basically just a square tube with little knobs on the top, sitting on a disk that has similar little knobs on the bottom.

Design for a paper cup holder

This particular design doesn’t benefit a whole lot from printing on its side, but it does benefit enough to try out the technique: if I printed the design as one, upright piece a couple problems would occur: 1) it would require a thin layer of support for the bottom disk, because the disk has knobs below it, 2) the knobs would break off easily, because the Z-axis binding of a 3D print is fairly poor, 3) the knobs on the lower disk would likely pull off when I removed the support structure.

So I cut the design into two parts, printed the parts on their sides, then glued the two parts back together. Here’s how I did it:

First, I created a block I’ll use to cut the design in half vertically.

design with a block to cut the part

In FreeCAD I subtracted the block from the design to create one of the two halves of the print, then I created a similar block and subtracted it from the original design to create the other half to print.

One of two parts to print

Here are the two halves, ready to come off the printer:

The two halves, printed with no support

Note how a square tube, cut diagonally, produces a part whose sides are at 45 degrees from vertical – which happily happens to be the maximum angle many 3D printers can print without support. So the cut parts have absolutely no support to remove.

The two halves of the design, ready to be glued

Let me reiterate that point Clifford Smyth makes in his book: it takes only 15 seconds or so to glue two printed parts together with Super Glue, while it can take a lot more time and more risk to your fingers (if you have to use a hobby knife) to remove support plastic.

In going through old family papers, I happened on a letter from my great-grandfather, John Foshay, to his wife, Martha (Whealdon) Foshay. It’s a letter composed mid-trip on a journey from Albany Oregon to California along what is now Interstate 5.

I love this letter for its sweet expressions of love, and for John’s vivid description of coach travel in the late 1800s in Oregon. Whenever I’m stuck on a plane waiting to depart, I think of John on the freezing floor of the coach, on page 2.

Canyonville Or. Nov 25/73 [1873]

My Dear Martha

You may remember that I told you in days of old that when I got lonesome I should write, and so, as the almanacs used to say, about this time look out for letters. I sent you a few lines from Roseburg yesterday evening. We only stopped there about fifteen minutes just giving me time to send a short note to Starr Meaby on business, and a word to you. I wish I could have seen Van Clive, but could not without losing a whole day.

There was only one passenger besides myself, and he sat out with the driver, so, I had all the inside to my self – more room than I wanted, for it was cold and foggy.

[pg 2]

The stage was not a regular coach but a covered hack. I got down on the bottom and drew the old leather cushions around me to keep warm – I don’t want any more such bed-warmers as they are. The driver started a very slow rate and I began to think the prospect of staging upwards of three hundred miles at such a pace was rather discouraging, but as the horses warmed up he let them out faster and the stage being empty and the road rough I got bounced around till I was not at all disposed to grumble about slow driving.

We got here about half past two in the morning, and I felt so cold and sleepy and tired that I thought lie over a day and rest. So, after getting well warmed I went to bed and slept till two o’clock this afternoon – I think I never did more real hearty sleeping

[pg 3]

in the same length of time and I feel just as good as new.

In the morning about two we start again. I intend to put on two pair of drawers and two under shirts and wear them the rest of the way down so that I shall be better protected from the cold.

I will write again before I get down, if we stop anywhere long enough.

I almost forgot to tell you that I came near coming back the day I went to the depot – Hart, the R.R. agent said that if I would wait one day he could get me a through ticket about ten dollars cheaper. I thought at first that I would do it then the thought of having to go back and bid good bye over again was too much. I was afraid if I had to do that I should give it up altogether.

[pg 4]

If you have not written to Kate Pringle you had better write while I am gone. It will give you something to help fill up time.

Here’s what the bottom looks like, with the USB (power, really) cable snaking out of it.

The underside of the finished scale

Next step: calibration. I read out the scale value for the empty scale; that’s the Offset. I then weighed a nominally-5-pound exercise weight on a food scale, then placed that weight on the scale and calculated the difference in value divided by the measurement from the food scale – that’s the Scale; the Slope; the second calibration to perform. With those two measurements complete, the calibration was complete.

Weighing the calibration weightweighing the calibration weight on the scale

Then to test the calibration, I weighed the partially-filled water bowl on the food scale, then weighed it on the bowl scale, and read the BLE (Bluetooth Low Energy) Arduino 101 output on my phone. Happily, the two readings were close: 1.168 kg vs. 1.170 kg.

Weighing the water bowl on the ‘standard’ food scaleWeighing the bowl on the bowl scaleThe water bowl weight read on my phone

I then modified the Raspberry Pi Node.js Service from my Dog Bed Scale to read the one weight from the bowl scale rather than the five weights from the dog bed scale.

With everything working, I created a stream on data.sparkfun.com, finished off the scale with a cutout from a waterproof placemat and placed the scale and the Raspberry Pi in the family room – score!

In my previous post, I started working on the scale. In this post, I finish the woodworking, and painfully re-learn the woodworker’s adage: “Measure twice; cut once”.

I was so excited about the progress I’d made, and so eager to finish the drilling that I carefully measured, drilled the holes for one half of the Load Cell, then counterbored the hole for the first Load Cell nut… then discovered in my haste I’d counterbored the wrong side, and ruined the bottom plate of the scale.

I counterbored the wrong side

Oops. So I started over, and 1 and 1/2 hours later I had finished the drilling… correctly this time.

The correctly-drilled bottom plate

Next I changed my mind about how to get the USB or power cable from the electronics to the outside of the scale without creating a path for spilled water. I decided to route a path on the bottom of the bottom plate so the cable will go from the Arduino 101 through the center hole, and out the routed path.

I’ve routed a path for the cable

“Measure Twice; Cut Once” part 2: Again I was trying to save time as I drilled the holes in the top plate for the upper bolts of the Load Cell… forgetting that the four bolts of the Load Cell are not the same size: the Load Cell bolts to attach the bottom plate are M5 bolts, while the bolts to attach the top plate are M4 bolts – they’re smaller.

Look carefully and you’ll notice that the left hole is larger than the right one – that’s because I used the same drill bit for the first of the two top holes as I made the bottom plate holes with… DOH! Luckily I can ignore the not-too-serious problem rather than cutting a new top plate.

Oops. The left hole is larger than the right one.

So the lesson of woodworking is to double-check before each cut into the wood, because you can’t undo a cut: “Measure Twice; Cut Once”

With the holes drilled, I test-mounted the Load Cell to the top and bottom plates of the scale. It’s turning out well.

The load cell test-mounted to the top and bottom

I then test-placed all the wooden parts and the Load Cell, to double check the left-right and top-bottom clearance of the bottom plate and the sides that will be attached to the top.

checking left-right clearance (scale is upside-down)Checking that the sides overlap the bottom a little, to keep water out

Next I glued the sides to the top plate.

Gluing and clamping the sides to the top plate

While the top glue dries, I spray-painted the bottom plate with a waterproof paint. This will keep moisture from causing the wood to warp and swell.

Now that my Dog Bed Weight Scale is sending data, I’m going to have a go at a water bowl scale. The idea is that, like the bed, the bowl will periodically send its weight to a cloud. This data should tell me when Pippa drinks, when we refill her bowl, and (maybe) how much she drinks.

The work-in-progress sources on Github, contain the beginnings of the Arduino 101 Sketch, Bill of Materials (Parts List), mechanical design/construction details, and a day-by-day project diary.

Since I was already familiar with Sparkfun’s Load Cell Amplifier, I only needed to pick a Load Sensor/Cell. I decided to go with their 10kg bar Load Cell because it should be easy to mount as a single-point weight sensor, and it’s relatively inexpensive.

I decided to construct the scale from 1/2-inch MDF (Medium Density Fiberboard) because it’s thick enough to minimize bending and it’s not too heavy. Although raw MDF swells and warps if you get it wet, that’s not a problem if you put a good coat of paint all over it – so I’ll be painting the parts before I assemble the whole scale.

With the major parts chosen, I sketched the to-scale wooden parts and the layout of the electronic parts.

to-scale sketch of the scale

I then cut the MDF pieces and bored the access hole that will let me assemble the last of the parts.

Cutting the access hole, using a Forstner bit

I then test-laid-out the parts on the bottom plate of the scale. Doing that reminded me that the assembled scale needs a way for a USB or power cable to get out of the scale. I decided to probably cut a diagonal channel in the bottom plate to allow for a cable – if I’d put the Arduino 101 where I initially planned to put it, the USB cable shroud would be in the way of the lid.

Note: the lid includes a water curtain on its sides, which needs to overlap with the edge of the bottom plate to keep spilled water from getting into the circuitry.

Rough layout of parts. Note the space required for the USB cable

I then used a drill press to drill the holes for the mounting screws and counterbore the holes for the nuts on the bottom.

I counterbored holes for the nuts

The next step was to make the connectors for the circuitry. I probably should have soldered thicker wires (an inch or so in length) to the Load Cell wires, because the Load Cell wires were actually too thin to crimp connectors onto – the Load Cell wires are very fragile.

Ready to crimp connectors onto the Load Cell wires

Because there’s only one Load Cell, and because it connects directly to the Load Cell Amplifier (unlike the half-load-cell Load Sensors I used in the Bed Scale), the circuit is pretty simple.

The assembled circuit (awaiting Load Cell mechanical parts)

I’ve ordered parts from McMaster-Carr to mount the Load Cell to the top and bottom of the scale. That mounting will look a lot like the Two Plate Configuration shown in Sparkfun’s Load Cell Amplifier Hookup Guide, except that my scale will have a lip fastened to the top plate to keep spilled water out of the electronics.

In my previous post I changed the uploader app to run when the Raspberry Pi turns on, and installed the scale under Pippa’s dog bed. In this post, I get interesting data from the scale.

The scale has been running for a little over a week now, and has been surprisingly reliable for a first version. There is some sort of bug in which, every few days, the scale stops supplying new data BLE notifications to the gateway. I plan to refactor the scale and gateway to avoid that, but that’s another post.

Today I looked at the data and saw some very interesting things.

Total weight in the bed, over 8 nights

You can clearly see when Pippa is in or out of the bed, from the large jump or drop in weight. Ignore the angled line – that’s an artifact of the scale stopping and the graphing program drawing through the missing data.

Most nights Pippa sleeps through the night, with one or two 15-minute periods of wandering around the bedroom in the middle of the night. On the two Monday nights, she seems to get up a lot more. Monday evenings we take Pippa to Nose Work class – the hobby version of bomb-sniffing dogs – where she works very hard, gets lots of treats, and gets dinner about 3 hours later than normal. We’re not sure which of these things makes her sleep poorly on Monday nights.

Weight from each corner of the bed over 8 nights

Pippa does flop around in bed every night. The above graph shows the weight measured by each of the four corner Load Sensors in the scale (again, ignore the angled lines). Whenever the values change, it indicates Pippa has shifted her weight in the bed – for example, by turning over.

If I want to see Pippa’s weight gain or loss, I do need to calibrate the bed better. If the bed were properly calibrated, the total weight on the bed should remain close to the same number as Pippa shifts about in bed. Looking back at the Total Weight graph, you can see how Pippa seems to become lighter and heavier as she moves around in bed – clearly not true. By the way, I’m now thinking of calibration as two distinct factors: 1) how closely sum of the four Load Sensors remains the same as the weight shifts (how closely the Load Sensors are matched), and 2) how accurately the sum of the weights reflects the actual weight on the bed. More on that in a later post.

Weight at the four corners for one night – July 12

Pippa shifts a little every few minutes, all through the night. Does this mean she’s uncomfortable? …dreaming of chasing rabbits? …listening to coyotes? …cooling off? More data means more questions.

In my previous post, I wrote the Raspberry Pi Node.js code to upload data from Pippa’s dog bed scale to data.sparkfun.com. This post covers how to make a Node.js program run automatically when the Pi is turned on. Oh, and at the end I installed the finished scale under Pippa’s bed.

Pippa, her bed, and the scale underneath

Advice to bloggers: Date your posts! I wasted a day trying to follow advice from a blog entry labeled “Dec 31” – no year – that described how to use /etc/init.d to create a Daemon (a process that starts on power-up and runs continuously). When I ran into problems, one of the (dated) StackOverflow comments I found pointed out that /etc/init.d has been obsoleted in Raspbian (the Raspberry Pi default OS) for a while.

Once I learned that systemd is the path to pursue, things went together pretty quickly. I found a wonderful post by Ralph Slooten describing almost exactly what I wanted to do.

Here is the file I created and put in /etc/systemd/system/scalegateway.service:

The really nice thing about this is that by saying “User=pi”, the script runs as the user “pi” – so it understands how to find the .cfg file I created in /home/pi, and (miraculously) understands how to find the Noble node BLE package in /home/pi/node_modules.

A few things to point out in the script above:

The Requires= and After= lines tell the system to start this service sometime after the bluetooth service is running – that’s because my script uses BLE (Bluetooth Low Energy).

This service description has no comments. I had a lot of trouble caused by systemd trying to interpret my comments as commands. So I removed all the comments.

Notice that I added NODE_PATH to the environment, copied from running “echo $NODE_PATH” as user pi. I’m not sure whether this is strictly necessary for my particular script, but it didn’t hurt.

I use the –use_strict flag on my node scripts so that I can find little mistakes that Javascript would otherwise patch over and hide.

The Install block is necessary to inform systemd that this is a service that can be manually installed. Without this, systemctl complained when I tried to enable the service.

Once I was sure that my Node.js script was running automatically at boot time, I unplugged the scale and the Raspberry Pi and moved both of them out of my office and to Pippa’s bed. The scale is under the bed and the Pi is plugged in to a wall socket behind Pippa’s crate (to the left of the bed in the photo).

A quick check of my stream on Sparkfun showed the live data was being uploaded from the bed to the Pi, and from there to Sparkfun’s data warehouse. The whole system is now uploading live, continuous weight from the scale – score!

In my next post I get to find out how much time Pippa spends in her bed at night while we’re asleep. Does she sack out the whole night? Does she get up and wander around? Does she flop about in the bed? We’ll see.

By the way, the nRF Master Control Panel (BLE) from Nordic is the perfect tool for debugging Bluetooth Low Energy devices and messages. It understands a pile of standard Bluetooth data types,as well as the Physical Web, so it’s a quick way to find out whether your Arduino project is sending the right data.

As you can see from the screenshot below, the scale is sending the Bluetooth Standard Weight Scale data: flags about what the scale supports, plus a weight measurement, in kg, and a user ID for that weight.

The Scale Data appearing in Nordic’s BLE debugging app

Once I could see that the scale was sending the right data, the next step was to set up a Raspberry Pi 3 to receive and process that data, using Node.js. I was surprised to find that although one big selling point of the Pi 3 is its built-in BLE device, it took me a while to find all the bits and pieces needed to configure the Pi to do BLE communications from Node. My resulting “how to” notes are in the CurieBleWeightMonitor repository, under piconfig.txt. That file describes how to configure the Pi out of the box, how to bring Bluez – the Linux Bluetooth stack – up to date, how to install a current version of Node.js, and how to install Sandeep Mistry’s Noble library for doing BLE I/O in Node.

My next step was to (re)learn Javascript in Node – it was a breeze. After learning a few basics about Javascript, I wrote a script that happily read data from the scale once per minute.

The next step was to a) setup a cloud to store the scale’s data, and b) write code to transfer the weight data to that cloud.

data.sparkfun.com is a wonderful thing for IoT (Internet of Things) experimenters: it offers public, free data storage for data from whatever devices you want to create. It was a matter of minutes to setup a Stream to store the data from the scale: total weight and the weight sensed by each of the four Load Sensors.

Armed with the public and private keys from creating that Stream, I wrote more Node code to format the weight data for Sparkfun and to upload it. You can browse the resultant data at the Pippa Dog Bed Weight stream on data.sparkfun.com.

Pippa’s weight scale on data.sparkfun.com

My next step is to configure that Node program as a Linux Service so that it runs when the Pi is plugged in. Once that’s done I can put Pippa’s bed on the scale, plug in the Pi, and start looking at real data.

To recap: I have built a simple IoT implementation involving a BLE sensor, a BLE-to-Wifi gateway, and a cloud data warehouse, and all the code is Open Source on GitHub. Imagine what you can build by modifying that code to, for example, track how much sunlight your living room gets over the year, how often you have visitors over, or when and how often your dog drinks from her water bowl.

In my next post, I turn the Node script into a daemon that runs at power-up, and I install the scale under Pippa’s bed – the end is in sight.

In my previous post, I designed and printed a Centering Guide to line up the top and bottom pieces of the scale. In this post, I finish assembling the scale.

Now that I have the Load Sensor Holders that I designed and printed, I drilled mounting holes in the blocks that will hold the Load Sensors.

Holding a Load Sensor over a support block that has mounting holes in it

(I used only the two front holes you see in the picture; not the other hole)

From there I lined up the support blocks on the bottom plywood circle, used a hand drill to extend the mounting holes through that part, then used a drill press and Forstner bit (on the bottom side of the plywood circle) to counterbore the holes that will hold the nuts that hold the bolts down.

Counterboring holes to hold the nuts

Note in the above picture that I’m using a support stand to hold the large plywood disk while I drill using the drill press. The support stand looks like a roller on a vertical bar. It’s a safety thing, to keep the plywood from crashing to the ground at the wrong time.

Closeup of counterboring

Once that was done it was an easy matter to line up each Load Sensor with the support blocks below it, slip the bolts through, and fasten them with the nuts.

The assembled Load Sensor on its support blocks

After mounting the Load Sensors, I mounted and connected all the other parts: the Arduino, Load Cell Amplifiers, Protoboard with resistors on it, and the plastic Centering Guide.

Mounted and Assembled Version 2 Scale electronics

Finally, here is the long-awaited, assembled version 2 Dog Bed Weight Scale, ready to be calibrated. It contains 4 Load Sensors, a pair of resistors per Load Sensor to change the Load Sensor into a Wheatstone Bridge, a Load Cell Amplifier per Load Sensor to measure the weight on each Load Sensor, and an Arduino to make sense of it all.

Top view of the assembled scale

In my next post, I’ll describe the Raspberry Pi code to transfer data from the scale to the cloud.