Sigurthr's Electrical Engineering Calculator

Sometime in 2014 I decided that I was tired of using online calculators for various common electrical engineering related equations. It was time consuming to use and annoying to keep track of. I shortly decided that I would write up a simple CLI program to act as a calculator for all these common equations. I completed about half of it by spring of 2015, and I filed it away to be completed later on. I pretty much forgot about it until early January of 2016, despite having a note on my whiteboard to finish the damn thing for the past year, haha. Thankfully I had it mostly done so it only took a few hours of coding to finish.

So, without further ado, I present my EE Calculator! Here is a screenshot of the function selection page so you can see everything it can do:

As you can see it is quite simple to use, but it is lightning fast and very light weight. Functions 2, 3, 6, 7, 9, 12, 13, and 15 are favorites of mine that I use quite regularly. On the initialization of each function the equation used is displayed, and the variables requested are explained. The program loops once the function is finished so you don't have to start it again to choose a new selection. Entering 0 at the function select screen or clicking the exit X closes the process and shuts down the program with no hanging.

Click here to Download my EE Calculator Program!

If you think of a formula or function you would like added to the program, just comment on this post and I'll see about adding it in!

Note that is is a .exe file so some browsers may object to downloading it simply because of the file type. Likewise, upon first run, Windows10 warns it may be unsafe, and you have to click "More Info" and then "Run Anyway" to get windows to allow it. It is 100% clean and free of any malware though, and passes all scans I can throw at it with antivirus programs. If you are unable to download it and want a zipped version, just contact me and I'll be happy to make one and upload it.

The Little UV Sensor That Couldn't... Adafruit's SI1145

So, I'll be rather quick on this, since this little bit of silicon doesn't really deserve more. I am extremely disappointed in Adafruit for endorsing such a piece of crap, but I suppose I can't expect them to actually thoroughly test every bit of tech they put their name on, certainly not items which need spectral light sources to test. They're a business, not a hobbyist or enthusiast who would actually be looking to use the products. Still though, 5 minutes actually looking at the output data should have clued them in that something is off. I will be writing them about this though, even though I know that is a futile endeavor.

The SI1145 sensor is *NOT* a calibrated sensor. It has two photodiodes on chip, which are both sensitive to the same spectral range of 300-1100nm. The only difference is that the two have different response curves within that range. Neither photodiode has any passband filtration on it, so neither photodiode can tell if it is reading Visible or IR or UV light.

Furthermore, it is *NOT ACTUALLY CAPABLE OF MEASURING ULTRAVIOLET LIGHT*. If you wanted to use this sensor to actually measure relative levels of UV light you would need about $200 in UV-Pass optics and a custom enclosure to block out all stray Visible and IR light. I happen to have such a set of optics from my UV-Photography equipment and was able to fully test this sensor. You'd also then be shocked at how horribly INsensitive this sensor is to UV. The fact that it is sold as a "calibrated UV index" sensor is a joke.

In terms of raw sensitivity is also isn't very sensitive either! It does have a decent dynamic range, but the range is all on the high intensity side. It takes about 100mW/mm^2 to max out the sensor, much higher than raw sunlight. What makes it seem like it is more sensitive than it is, is that the damned thing never reports 0, even when in perfect darkness! I put the sensor inside a Lead Shielded "pig" and still got readings of ~254 on the IR and Vis channels.

Here's the response data from the datasheet:

As you can see if you wanted to use it to measure relative light levels of any specific type you would need the associated bandpass optics and a suitable stray light occlusion enclosure.

So, what does this chip actually do? It reads the Vis and IR photodiodes and reports the readings over I2C. The "UVindex" data that Adafruit's library produces is just a mathematical adjustment made to the visible light photodiode's reading. This is meant to approximate a UVindex reading that corresponds to a given visible light intensity in clear weather sunlight. It is the literal equivalent of saying "this is about as bright of light as it was outside that day when the weather channel said the UV index was X".

Without having to add on expensive bandpass optics the only use this sensor board has is to report non-qualitative, relative light intensity over I2C. It's basically a fancy CdS Photocell LDR. Use it as such, and nothing more.

I've rewritten the Arduino code for this sensor board to reflect my findings and output non-fictitious data. You may use it freely, but since it still uses Adafruit's library do give them credit if you use it.

Download My Code and the Adafruit Library for this sensor Here.

Phasing a Pentafiliar Gate Drive Transformer (GDT)

So you've made yourself a sweet Half Bridge SSTC or DRSSTC, and now you want to increase your coil's performance by moving to a Full Bridge. Adding the extra transistors, diodes, resistors, and doing all the additional layout is really the hard part, but I get asked all the time how to phase a GDT for a full bridge as if it is this mysterious perilous endeavor. It really isn't any more difficult than doing a GDT for a Half Bridge.... IF you have a Dual Channel Oscilloscope. Unlike with a simple Trifiliar GDT, you cannot rely on process of elimination alone to determine the phasing. This time you really do need a signal source and a scope. Now I should say, you can simply use two Trifiliar GDTs in parallel, but you must really try hard to balance the impedances or your bridge can fail catastrophically from cross-conduction ("shoot through"). I find it simply isn't worth the risk. Not to mention, you need to compare phases between the two trifiliar GDTs, and that really isn't much easier, but it could be done provided you have a signal source and a meter that can measure differential ac voltages. That's a topic for another day, and one I'm not inclined to broach honestly.

What I've done here is show the results of properly phasing a Pentafiliar GDT through images. I also include an image set at the end that shows what happens when you probe a winding with the "wrong" phasing. This is of course what you'd see as you are determining the phases. I wanted it to very clear what is going on and what you're looking for, so you have to see what the "wrong" result looks like to know what the "right" result is.

I didn't show the process of winding the GDT, or pairing off individual windings with an ohmmeter/continuity meter, but that's the same as with a Trifiliar GDT, you just do it with four more wires.

I've already labeled my windings "A" and "B", with the indicator on the "Gate" side wire. B is antiphase of A, and of course to reverse the phase of a winding we just swap the wires. Pay attention to which wire the scope probe is on, even though I do state it clearly. We keep the first channel on a single arbitrarily chosen winding the entire time, making sure to never reverse the connections to that winding. From this we have a stable comparison point to reference the second channel against.

I also used my 1MHz sine discrete signal generator because I wanted to show that these cores I use and my techniques really are good at 1MHz like I claim them to be! You might note that compared to the first image, when the second probe is added the amplitude drops by half. This is because my 1MHz source is a very high impedance source, around 4Kohm impedance, so the low impedance GDT windings are loading it significantly.

Here you can see that it really is a 1MHz signal propagating through the GDT into Channel A of the scope.

Now we've added Channel B, this time I set it to look at an in-phase winding. You can see the signals are identical and in phase. In the middle image I shifted channel B down a bit in the Y axis so you can indeed see the waveform distinctly.

In this image I picked an anti-phase pair, but reversed my connections to that phase. This means that signal is in-phase. This is the opposite of what you want to see on an anti-phase pair, so you know you have to reverse the connections.

Here we're looking at the phase relationship of two anti-phase signals. You can see now I have the scope probe actually on the "Gate" wire instead of the ground clip being there. This is what you want to see between an "A" pair and a "B" pair.

Arduino and ATTiny85 SSTC Interrupter - Version 3!

While doing the programming for the V2.0 revision I decided that I really wanted to try my hand at making an interrupter all on my own, without relying on someone else's code as a basis. While it sounds like an easy task it really is difficult because of the hardware limitations inherent with the ATTiny and ATMega chips. Primarily, they overflow variables at 2^15, which means if you're doing math in microseconds you can do frequencies below about 32Hz. You can of course do math in milliseconds, but you can only do integers, not floats, so timing accuracy and variability suffer. The way around this is to cleverly use both uS and mS to achieve your desired goal.

I wanted to make improvements upon the previous version of the software, and while I have done that in some regards, in other ways V2.0 is superior to V3.0. Particularly, I found there is a hardware glitch present between 34Hz and 54Hz where the internal timer subsystems don't trigger the GPIO pin states correctly despite having the correct values in the variables. I thought about writing to the hardware registers directly and avoiding delay() calls but it really didn't seem work it. So, I simply set a fixed duty cycle for this 20Hz wide range and decided to live with it. If you want no interruption in duty cycle variability, use V2.0 instead. However, V3.0 does have some nice features; no limit on maximum duty cycle. I've tested it up to 95%, though the current default implementation only allows for 50% maximum as I couldn't really find a use for >50% duty during field testing. I have a version of this software available upon request if you would like it, just tell me you want "rev 3.0, not rev 3.1". 3.1 is the internal name for this 3.0 release because if I labeled it 3.1 everyone would ask me "you went from 2.0 to 3.1?". It's a lot easier to modify the minimum and maximum frequencies now as well with clearly labeled variables for these two parameters. Minimum duty cycle is set at 2.5%, and going so low involves some clever use of nested conditionals to avoid pitfalls that occur when you aren't able to use floats in some places and are limited to 2^15 in other places. V2.0 avoids this by limiting maximum duty cycle to 10%, V3.0(internal) avoids this by limiting minimum duty cycle to 10%. So in this release we actually have 2.5%-50% duty cycle output.

Like with V2.0 there's reduced GPIO and Hardware requirements, and as such CW mode can be accessed by turning the frequency dial to maximum. I've ported the code to Arduino for ease of use as well. I've learned to loathe the ATTiny85 chip over the years simply because of its increased limitations and lack of an integral USB interface or bootloader.

Here's the files and diagram for the Arduino UNO version:

Download Source Code Here

Download Diagram Here

Here's the files and diagram for the ATTiny85 version:

Download Source Code Here

Download Schematic Here

ATTiny85 SSTC Interrupter - Version 2.0

I finally got around to revising the code and schematic for my original SSTC interrupter. I do want to point out that this is still heavily based on Gao (loneoceans)'s code and he really deserves a great deal of credit for it. See his website here: http://www.loneoceans.com/labs/

Without going into the ins and outs of the code here are the abridged changes:
- Reduced the number of GPIO pins required and moved away from using the MISO/MOSI pins. Having those two pins used causes some programming issues, especially when you're using a digispark or similar device that doesn't have a standalone usb controller.
- Reduced hardware requirements. Now it only uses 2 pots, 1 resistor, an NPN transistor, and the FB-129 transmitter (outside of the power supply section). In the previous version the LED of the FB-129 really stressed the GPIO current handling, and it lead to early failure of some less robust chips.
- Reduced the default max frequency to 256Hz. You can change it back easily in code.
- CW mode can be accessed by turning the frequency dial to maximum.

This still uses Gao's algorithm for frequency and duty cycle synthesis, so it still only allows 10% duty maximum. If you want an enhanced duty cycle range, see my later post about Version 3.0 .

Here's the updated schematic and code files:

Download Source Code Here

Download Schematic Here

Arduino - True Binary Digital Clock

So, nearly a year ago I posted this: http://sigurthrenterprises.blogspot.com/2015/01/arduino-binary-clock-serial-output.html It basically is the intent statement for the binary clock I was developing and a teaser sketch. I fully developed my clock shortly after posting that but life got busy and I never got around to publishing the results. Today I rectify that oversight.

I've always thought binary clocks are cool. Unfortunately, most of them are LED based and used BCD instead of real binary output. BCD takes up a huge amount of space and is far slower to read than real binary, so I knew that isn't what I wanted. Also, if you're going to do it on a microcontroller, it takes a ton of GPIO ports to do BCD. After scouring the net for days I couldn't find a single clock that outputs the time the way I wanted, so I knew I had to make it...

As you can see, it's really quite simple. Thanks to the I2C "TWI" communications interface it is very easy to put together and interfaces beautifully with readily available inexpensive peripherals. The real magic happens inside the C program written for it. Here we poll the Real Time Clock for the current time (integer) and do some math and a clever trick using the itoa() function to convert that value into binary (string). Then we send the data to the LCD which updates once a second. Not content with an ill-centered output, I added a series of conditional statements to pad the MSB with [string] 0s as needed to keep the time centered on the screen.

Here is the data file you can download that contains all of the files; source code, required libraries, parts list, and instructions. Enjoy! Binary Clock Data File

If you just want to see the source code here is the stand-alone .txt file.

p.s. I do NOT recommend using the housing I used. It has been a serious pain in the ass because the inaccessible nuts that the screws mount into are set into blind holes which have not been bored out to accommodate said screws. Additionally, the housing's thickness is not great enough to allow pin header cables to connect normally to the pins on the back of the I2C LCD. I had to bend the pins 90deg and then solder the header cables to it. I didn't explicitly show it, but the RTC module nests nicely on the right side of the UNO in the space there, requiring no mechanical restraints.

New X-Ray Cassettes Came In... New Radiographs to see!

The two x-ray cassettes I ordered came in, and my research rang true; both are green emission and far better quality and performance than the old Cromex blue I had initially used. I got one X-Sight Regular X-Omat and one Lanex Fine X-Omat, both by Kodak.

It took a few hours to work out the best exposure times and settings but I eventually nailed it down pretty well. Even with dark frame subtraction and keeping the camera off axis of the main beam there's tradeoffs to be had. In the end I found it best to use a wide aperture and put the camera On-Axis. The reduced thermal pixel noise greatly outweighed the increased x-ray induced pixel noise.

To my surprise the Fine screen isn't that much finer than the Regular screen. I think though the difference would be highly noticeable if I were using X-Ray Film and trying a magnified imaging setup. Since I'm just imaging the phosphor screen using digital photography the increase in resolution is negligible given the increase in noise due to about half the amount of light production.

X-Sight

Lanex Fine

 

Usually I prefer the as-shot radiographs, but sometimes the traditional negative view looks better. I'll include whichever works best, or if it's a tie, both.

Lanex Fine