Voltage Monitor V2.0

This is an automotive Voltage monitor. Draws 7mA in deep sleep mode.

Battery Monitor Board

This board was soldered with an iron because I didn’t feel like grabbing the solder paste and setting up my air station for a few small components. I think I prefer the air station for the tidy solder joints it gives.

Eagle files are here:


Here is a simple program to read the voltage. Note that it relies on the resistors being correctly set up (460k/1M) and may need to be calibrated. Note that while the base ESP modules work with a 1V comparator for the ADC, some development boards work with 3.3V (or supply voltage). It only writes to the serial, full HTTP integration will be coming shortly.


Kiln monitoring and fan control with ESP8266

(More detail to come)

This is a board I created to monitor kiln temperature and allow fan control with an esp8266

It features micro-usb input, a MAX31855 chip for thermocouple (type K) interfacing and two opto-isolators for control of a solid-state relay (pictured) or other purposes. I only need one, technically but I had GPIOs to spare.

I made three mistakes on this board that I would change in a redesign. The first is that I connected a resistor to GPIO2 instead of CH_PD. I have no idea why I did this, I think I was looking at the instructions for startup requirements and got something lodged in my head. Fortunately, this was easily fixed with the addition of a resistor. Second is that I wired the opto-isolators to be on when the pins on the ESP are pulled high. The opto-isolators would like 20mA which would require a 100 Ohm resistor and the ESP can happily sink 20mA but they can only source 12mA. Fortunately, they work well with the 12mA available from using 120 Ohm resistors but I did not have any of those on-hand so had to wait for those to arrive. The third mistake is that I put some silk-screen writing on the wrong layer and one of my components also had its silk-screen on the wrong layer. This could have been caught by inspecting the gerbers, of course but it’s non-critical so was overlooked.

Technically, the SSRs should be able to operate on 3-32VDC but I have had trouble getting this to work from a Raspberry Pi before, hence the opto-isolators.

Sorry about the screw terminal connectors. The ones I ordered never arrived and I have another batch incoming. I only need one for fan control anyway so this works for me.

This was my first real foray into working with SMDs. I was using a reflow air station. It worked well but I had some issues with the ESP. Because the PCBs are so flat, the solder paste pancaked and caused shorts and because there wasn’t much room for airflow, the paste under the board didn’t melt. I ended up using regular solder and an iron.



Using the physical web with beacons and Eddystone URLs.

I was hanging out at the Nashville Game Jam when I noticed several unrecognized notifications for websites pop up on my phone. Not something I’d seen before, I had to look into this interesting new (to me) thing. These turned out to be Bluetooth beacons configured with Eddystone URLS. On recent Android phones, the default Google software includes something called “Nearby” which, if Bluetooth and locations are enabled on your phone (which I guess they probably are for most), if it picks up the appropriate broadcast code, it will display a notification with an icon, a link and a short description. With a little work, I was able to get this working for my own needs and I will describe how.

I was already a little familiar with Bluetooth beacons from a locating project at a previous place of employment but this was a new thing on me. A Bluetooth beacon transmits (and potentially receives) specific data packets. There is a variant of this which is called an Eddystone URL which is a format which slightly condenses a URL in order to fit it into a data packet.

If you want to dip your toes into the water and you have a Raspberry Pi, you’re in luck. If you have Bluetooth (and the Pi 3 has this built in), you can make it behave as one of these beacons. I found excellent instructions here. This may work out-of-the-box for you but there are several pitfalls and trick that are not well documented. The page is also an excellent source if you are interested in familiarizing yourself with the Eddystone format and the Pi’s Bluetooth operations without getting into too much depth.

Google pre-verifies the web page: The Nearby app also does not retrieve the information from the web page directly but it is loaded within their network and forwarded to the Nearby app.
Google’s pre-verification is cached: If you make an error which means that Google will not pass your page to the Nearby app, once you have corrected it, it may not recheck the page for a long time. I have not managed to pin down exactly how long but I have seen *at least* 4-6 hours. There appears to be no way to force a re-check. This also applies if your page is working and you make changes.
The URL must be an https URL: Google decided for reasons that the URL must be an https url. It’s not well explained but I suspect that this is to prevent people with open WiFi hot-spots from directing people to websites and stealing information. https, in theory, at least ensures that people are connecting to the sites they believe they are.
The certificate must be valid: This seems like a no-brainer but it eliminates self-signed certificates, expired certificates and certificates that don’t represent the site. As an additional wrinkle, I was running with a certificate from StartSSL which several providers decided to revoke their CA status and my certificate chain became invalid, causing my URL to no longer function. Easily fixed by obtaining a certificate from a different provider but something to be aware of.
The page must have a title tag: Easy to miss when you’re doing some quick testing but if you don’t have a title tag, you won’t show up in Nearby.
Icons: The usual browser icon types seem to be supported. favicons or link tags work.
Redirecting: Main website not on https and thinking of just doing a redirect from the https site to the http site? Don’t. Google detects this and if the final endpoint of the page is not https, it will not show up in Nearby. This applies both to HTTPS header redirects and HTML meta tag redirects (I have not tried extended times on the meta tag, only 0s redirects). I have not tried JavaScript redirects but there’s a chance they detect those also. It might be possible to serve google different pages without redirects than you do to other users but I have no idea what would happen if Google detected this.
Pre-verification: You can pre-verify your page here. Note that this doesn’t seem to detect some error conditions such as a missing title tag and my unacceptable StartSSL certificate was verified fine but it is helpful.
Description: The description is, by default, taken from the text on the web page. I have not determined if there’s a way to specify the description in a different way. However, there is a meta description tag which is probably the answer to that question. I will be testing that.

Having succeeded with the Raspberry Pi, I wanted a more efficient version than a small computer running at 5V, 1A so I bought two small battery-powered beacons. More on those later.

The Ever Changing Next Halving Date

Note that I accidently ran this data from between the middle of the two halvings. I believe the interpretation still stands but I will run a complete analysis from the last halving tomorrow and update

For mining blocks in the Bitcoin blockchain, Satoshi designed the algorithm so that the difficulty would be periodically adjusted in order to have a block discovery time of ten minutes. However, with the rising interest in Bitcoin, mining power has kept ahead of the difficulty adjustments.

In order to see how this balancing act has proceded, I took all the blocks from the time of the last halving and calculated the average time to mine the blocks on a daily basis. (Note that I calculated the average over the period since the halving and not just on the day in question.