B&K 2831E Digitial Multimeter Review

I recently had the opportunity to bring home a new piece of test equipment, so I thought I'd tear it apart and take a look inside. The B&K 2831E is a 4 1/2 digit bench multimeter with some nice features and fairly good specs. From personal experience I already know that I like this instrument, but I hadn't had a chance to look inside until now.

First impression on opening it up was sort of "that's it?" because for the most part there is only a single board which isn't even densely populated. Based on its specs (e.g. 0.03% VDC accuracy) I was hoping to see a lot of high-precision resistors and other neat things like that. There is only a single large thick film resistor and a ceramic cased power resistor (seen below along with the 4 wire connections from the front panel). Towards the back of the unit is an IC related to the USB and a pair of (in white package) optical isolator ICs. The RS232 IC and connector can be seen missing nearby, which is a feature on the 5491E. Two black boxes seen below are some of the various relays used for switching between various modes and scale settings. The one on the right appears to be heat damaged, possibly from soldering and hopefully not from that nearby red wire. This could be related to the unit's problem which is that it gets stuck during the self test (relay not switching in test signal perhaps).

One of the unit's fuses is inside, connected on a sub-board of the front panel. The copper bar is a current shunt. It is a known value, usually trimmed by shaving or clipping, used to measure the amount of current passing through it. You can also just about see the two ferrites as well which help reduce noise on those lines.

On the main board there is an RF enclosure which I opened to see what was inside. Nothing really stood out as out of the ordinary and I'm not quite sure why this section needed to be shielded. Are they producing a signal which must be contained or are they being shielded from signals? The shield does not contact the exposed landing evenly, so I'm not very impressed with the RF shield, if it's even needed. Here is the list of some of the ICs in that section:

ES636 - RMS to DC converter
LM393 - opamps
HEF4066B - quad analog switch
OPA4343 - opamp

The main processor for the BK 2831E is an Atmega 128A which is an 8-bit microcontroller with 2 8-bit PWM channels and an 8 channel 10-bit ADC. Not knowing as much about Atmega micros as I do about PICs, I can't provide much insight into it's outstanding features, but it seems like a capable part. Perhaps the bulk of measurement is done with this unit, which if the case then I am rather impressed considering the 0.03% VDC accuracy. I couldn't find a precision reference voltage, but I will have to take another look. The 12MHz clock crystal for the micro is right next door.

In the picture above you can see the microcontroller as well as several caps, voltage regulators, rectifiers (very bottom edge of screen) and some loops passing through ferrite (left side below row of caps, presumably filtering). The main voltage transformer sends various voltages to this section where they are rectified, filtered and regulated. I measured +5V, -24V, and 2.5V, but I may have missed some. The connector on the right goes to the front panel display PCB.

As mentioned earlier, I am a fan of this type of VFD and in general I like the looks of the front of the unit. Front panel controls are very easy to use with a single hand and intuitive. The front panel power switch connects to a real line switch in the back via a brass rod. Real line ("mains") switches are always an appreciated feature. One complaint I have with this meter is that my Probe Master probes which use the safety-type banana jacks would not easily connect to the front panel sockets shown here (I had to use a fair bit of force, but they do work). I'm not really sure whether that's the fault of B&K's design, but I can tell you that those probes work easily with other meters.

In terms of features it covers the standard range of Volts and Amps AC and DC, resistance, continuity, diode, frequency and period. The accuracy and range of these measurements is good and comparable to what you would expect from similar 4 1/2 digit meters. The DC range goes up to 1000V, which I have been meaning to try, but haven't gotten around to it. Ranges that high and more are useful for me to be able to measure directly with some precision. One slight disappointment is that the frequency measurement only goes up to 1MHz, although the accuracy is good. It's not a frequency counter after all and I personally have instruments that can measure frequency much better, but it would have been nice to have more.

One of my favorite features is the ability to perform two measurements at once, for example Volts AC and DC or Volts AC and frequency. That is a nice feature, but it does slow down the front panel display update rate to about half. In normal mode the update rate has 3 settings (fast, med., slow) which is useful depending on what you're looking at, although it's important to remember it affects the accuracy (slow is best accuracy).

Something interesting about the 2831 instruments is that as you go lower in letter (2831D, C, B etc) you seem to get older instruments. Normally I am used to test equipment manufacturers updating their numbers on new models, but maybe this is just how B&K does it. It's something to keep in mind when you're shopping around though. It might be interesting to see how the instrument evolved over time. For me personally, I would definitely prefer the E model over any others as it is the most modern looking (I like the smaller teal colored VFD over the older red LED style display). I don't know how the specifications compare between versions.

All together the B&K 2831E is a nice unit on the bench and I would buy another one if I needed it (and I have, in fact). I have a Yamaha PSS-680 digital synthesizer keyboard that I want to take apart and do a tear down of. I'm not sure how much of the circuit I would be able to identify and I don't feel qualified to review it, but since I have the need to take it apart for cleaning I thought it would be interesting to have a look. I am also still planning to talk about my HP 3585A spectrum analyzer, but it will probably take longer due to it's complexity.

Controlling a Negative Voltage Outuput in a Control Loop

I know it's been a while since I last posted and I've been rather busy. Hopefully I can get a chance to post more often soon. I'm thinking of doing a semi-teardown of a HP 3585A Spectrum Analyzer. Now, on to the problem:

Let's say you have a device in your circuit that outputs a negative voltage, but all your control and power supply voltages are positive. How do you handle feedback of the negative voltage with the positive control signal? The short answer is "with a summing junction," but I've written a little more detail on it.

Fig.1 - Click to enlarge

Let's start with the voltage divider. You should design this such that the full output of your feedback (your negative voltage) is divided down to the negative of the maximum control voltage. That's assuming this is the correct sense that you want, maximum positive control voltage equals maximum negative voltage output. In other words, for maximum output divide down to -5V for a max control Voltage of +5V. I also added a small capacitor here, which adds some filtering and helps with phase margin.

Next is the all important summing junction. You should design this to zero out the command voltage when a matching feedback voltage is present on the voltage divider. In other words, at full output the divider should be at -5V and control voltage at +5V so the voltage at the midpoint of the summing junction should be zero Volts. Ignoring the summing junction, these resistors would be equal, but you could also design it for +3V to zero out -5V or something. Compensate for the divider by calculating the parallel combination of the lower divider resistor and the feedback side resistor of the summing junction. Then set the control voltage side resistor of the summing junction based on the balance you need. Finally, it is best to set the summing junction resistor values at least 1 order of magnitude higher than the lower divider resistor in order to avoid influencing the divider ratio. All these values are calculable using basic electrical theory (Ohm's law, Kirchoff's laws, etc).

Example: Assume R4 = 30k, Max Feedback Voltage at divider cap = -5V and Max Control Voltage = +5V. For zero volts at summing point at max control and feedback, R5 = 330k and R6 = 300k.

Finally is the control section of the circuit (well, it's all part of the control loop really). In my application (a high voltage negative power supply) I used an operational amplifier. You could use a microcontroller or other methods depending on your needs, but be aware that you may have negative voltages at the summing junction with certain conditions. My opamp is set up as a noninverting amplifier, with added low pass filtering. Set the values here so that they filter out any noise you expect to receive, but also have a reasonable response time.

Something important to consider with R1 and R2 (the opamp resistors) is overall loop gain and stability. You may need to (depending on your application) design the opamp and overall loop gain such that the gain is 1 or less (R2 <= R1). The reason for this is that with high gain and multiple phase shifts you can get your control loop into a situation where it is oscillating itself. This is called loop oscillation and is generally to be avoided. Filtering also helps with this. In my application, the high voltage negative power supply constitutes a high gain block which had multiple unpredictable phase shifts inside it which could cause loop oscillation if not planned for and controlled.

Keep in mind that the negative output of your device or circuit does not necessarily have to be linear, but it must be monotonic. Here is an overall description of how the circuit works:

At a steady state of 0V output with everything powered up, the Control Voltage is switched from 0V to +5V. Since the voltage from the divider is 0V, the voltage at the summing junction becomes a positive value. The output of the opamp starts increasing, which goes to the control input of the device or circuit and the output of the device starts increasing (going towards some negative voltage). At some point, the output of the device reaches the desired value and feedback from the divider equals -5V. With the feedback value = -5V and control voltage = +5V, the voltage at the summing junction is equal to 0V and the opamp's output stops increasing.

 Assume a semi-steady state where the Control Voltage = +5V, feedback voltage = -5V and output is at a desired level. Now the control voltage is reduced to +2.5V. Since the feedback voltage is at -5V, the value at the summing junction is now -2.5V which is seen by the opamp. The opamp starts decreasing its output thereby controlling the device to reduce its negative voltage output. Eventually the control voltage and feedback voltage balance where the output of the device would be about 1/2 of its maximum output (2.5/5).

Please note that it is not necessary to have a negative power supply for the opamp, as the goal is not to output a negative voltage from the opamp, only to reduce its output. I hope this is helpful to someone, even though it may be considered fairly basic it may not be entirely obvious.

PS3 Controller Quick Look Inside (Dualshock 3)

We have a PS3 controller at home that was starting to act buggy so I decided to take a look. Really the technology inside is pretty impressive. Unfortunately the microcontroller is difficult to find any info on, but I do know that it has some accelerometers and gyroscope in it to be used for motion sensing control.

There's a decent sized 570mAh lithium ion battery inside, and I was surprised to see that there is actually two motors with different weights (for vibration effects).

Above is a picture of the main board with the mystery microcontroller. You can find some information on it (I'm not the first to take one of these apart), but I found it impossible to get any info on its specifications, much less a datasheet.

The malfunction we were experiencing is that controls on the "D-Pad" would activate either when the analog control stick was being used or just on their own. The front board connects to the main board via a flex ribbon cable. The D-Pad is made up of switches on the front panel while the analog control sticks are soldered to the main board. I think the cause of the problem was this flex cable connection point. I will try cleaning the mating surfaces and see if it has fixed the problem.

Cerberus Alpha: The Lettercase Issue and Finalizing

The issue of lettercase was really the last major hurdle that I had to jump over so I was a little anxious to get it done already. I decided to take a relatively simple approach; if at first you don't succeed, try and try again. Since the intended use is for Windows 8, Cerberus Alpha assumes that the file-name format should be that used in Win 7 / Win 8. If it doesn't get success with that then it tries the other possibility. Technically, this doesn't account for every possible scenario so I still consider it flawed. Will the target program even work in windows if it is not the correct case format? I don't know, but Cerberus Alpha tries to make sure that it replaces with the correct lettering format when undoing the changes. I think that it should be possible to account for every permutation of case, but it would have been more involved than I wanted to code at the time.

I also worked to improve the success counter, but I made a couple mistakes and it didn't work. The program still worked, but it did not correctly report success and therefore did not reboot when finished. That could be really bad because if you try to install twice in a row you could lose your original utilman.exe or sethc.exe. The mistakes boiled down to not having whitespace in the if statement and an incorrect format trying to iterate the second success counter. If the copy command succeeds it does ((successA++)), but successB++ doesn't work on it's own line.

Following this I also fixed the menu screen so that it will appear correctly in either terminal. It is very simple in that it checks if $TERM is "rxvt" and then prints the menu accordingly.

Finally I completed a menu option for uninstalling the sethc.exe patch. I don't know why I didn't do this earlier, but there it is.

And that about wraps up the project. The only thing left to do really is to burn the final version to CD and get it tested on some real world cases.

Cerberus Alpha: File Format Problem and Small Update

I've been busy at work so it's been a while since the last update so I wanted to make a quick post. I've made a little more progress and handled the lettercase issue, but I'll talk about that in the next one. I was going back and forth through so many different editors that I made the mistake of saving a new version directly from Notepad on Windows. That caused some "file not found" errors when trying to run the program, although "ls" and "cat" could find the file fine. I opened it in nano and tried a few things. I didn't notice at first, but nano was saying something about MS-DOS mode, it was an easy to miss message. I found this little command very helpful:

head -1 yourscript | od -c

It would out put

0000000 # ! / b i n / b a s h \r \n

if the format was not correct and

0000000 # ! / b i n / b a s h \n

if the format was correct. As you can see, there was an invisible trailing carriage return after #!/bin/bash that was causing the issue. Apparently due to the MS-DOS text format. Following that there was a simple dos2unix command installed on my system that magically took care of the problem. I don't know if dos2unix is on TinyCore (was using Parted Magic at the time), but if it isn't I may include it. Although, best practice would be to use caution with your file formats because the problem is not immediately obvious.

Anyway, next time I'll talk about the lettercase fix that I made in 1.5 among other things. Hopefully the project will be complete in the next couple weeks!

Here are some screenshots of the main menu:

And Cerberus Alpha's "title screen." Enter 'a' at the main menu.

Cerberus Alpha: NTFS File Systems and Letter Case Headaches

On my test virtual machine I formatted the drives as FAT-32 without thinking, but in reality many Windows drives are formatted as NTFS by default. When I actually tried my test CD, it gave me an error stating that the file system was read only. I thought this was due to some error in the implementation of the mount function, so I tried a few modifications to that. When I finally got around to searching the internet for advice I found that the version of mount on TinyCore Linux by default does not have the ability to mount NTFS file systems. Tiny indeed!

To take care of this issue, all I had to do was add "ntfs-3g" into the list of utilities that my remastered OS would load. With that installed, mount would load the Windows file systems as read-write and cp worked as expected. Before I figured this out, I thought that my output suppressing statement was an issue (1>/dev/null 2&>1) was causing the issue and it actually did actually seem to be a problem because it seemed to mount the file system to /dev/null. I may have to take a look back and see if I can put that back in and it will still work.

The next major issue is one of letter case. I can expect certain files to be named differently depending on the OS:

• Windows XP:
• /WINDOWS/system32/
• utilman.exe
• sethc.exe
• cmd.exe
• Windows 7:
• /Windows/System32/
• Utilman.exe
• sethc.exe
• cmd.exe
• Windows 8:          (need to confirm)
• /Windows/System32/
• Utilman.exe
• sethc.exe
• cmd.exe

I can't say for certain that these are the only possibilities, but at the very least there are two paths and two file names I could encounter. One shortcut I could take is to tell cp to access /*indows/*ystem32 and *tilman.exe, but aside from the fact that ignores the all-caps version of "WINDOWS" this still has a big problem. What do I copy to? If I copy *tilman.exe toutilman_bak.exe for example, how do I know whether I need to copy cmd.exe to Utilman.exe or utilman.exe?

I've come up with a few solutions, but none of them I really like. At the moment, the program assumes you want the Windows 7 version if you're copying Utilman, and the Windows XP version if you're copying sethc.exe. I could assume that Windows doesn't care about the case of Utilman, and then just only deal with the "windows" case issue. Or I could make the "thorough install" option attempt to copy all different possible versions, starting with the most likely. That would slow it down though. I also read something about a "no-case glob" option in bash, so I will have to explore that.

This case issue is what I'm working on at the moment. Another issue I'm working on is that my message regarding number of successful installs does not count correctly, but I may just scrap that idea as it's not very important.

Cerberus Alpha: Remastering the OS to Load the Program on Boot (Part 2)

Hello! I decided to take a break from the project, and the write up, because I got really busy at work and had to do some traveling. I will get back to the project when I can, but for now I'm going to fill in the rest of the write up while I can. I'm going off of memory at this point, so some things might be less detailed than I'd like.

When we last left off, I had finally discovered the correct method for integrating my program into the remastered iso of TinyCore Linux. The next step was to find the correct place in the boot process to load the program. Some of this really happened side by side, but I thought it would be better to describe the process in two parts. This was really a learning process for me because I needed to find the right time to run my script and TinyCore seems to have an atypical boot up process.

As mentioned previously, my first attempt was to place cerba.sh in /opt/ and modify /opt/bootlocal.sh to start cerba. According to the TinyCore Linux wiki, bootlocal.sh is run "later in the boot process." Unfortunately, it was not late enough. I tried a few implementations of this (changing around the order in bootlocal.sh), but they never worked. The behavior was that it would start cerba.sh, but the behavior was that it would run in an infinite loop (at the main menu) and ignore user input. It seems as though the bash interpreter was not yet running and that bootlocal.sh is more for things like selecting the keyboard layout.

If you search around the internet a bit, the bootlocal.sh option is mentioned a few places, as is placing your script in .X.d to boot, but this would not work because that only runs after the X window system has started and I did not want to wait for that process. My next attempt was to place start cerba from /root/.profile. This was good because it ran the script as root user, but it still had the flashing / looping issue. I tried /tc/.profile (tc is the default login user), but it still had the flashing issue. Another issue that I had was when calling on the script from the .profile I originally placed "exit" at the end of cerba's quit function. This would either exit the boot process entirely, or it would log out the existing user, interrupting the boot process awkwardly. There were other issues encountered that revolved around mounting the file systems and other commands in the script, but I can't quite remember when they were resolved. Either way, it had to do with running cerba at the correct time once all the utilities had loaded.

My next attempt was something that I had to do a little digging to figure out, but once I had it this was essentially the correct solution. I put the script in /etc/profile.d/ and this time it ran correctly without any errors (related to its placement in the boot process at least), except for one. When the program ran, it worked fine, but when I chose to "quit" from the program it would rerun itself! As it turns out, the program was being started from /etc/profile.d/ every time the user logged in, so when I quit the program it tried to login again and reran cerba. My simple solution to this was to place cerbastart.sh which was simply a script that did "sudo cerba" and then "rm /etc/profile.d/cerbastart.sh ." This was my way of ensuring that the program ran once and only once during the initial login. The added benefit of this is that cerba will run once and then continue to boot normally, including into the X window system if that boot option is chosen.

Around this time I placed a copy of the script as /usr/bin/cerba which meant that I could run the program just by entering "cerba" in the terminal. Every thing seemed to be working perfectly so I burnt a test CD and tried it out on my machine at home. When I ran it, though, there was an error about the file system being write protected! This was my next major hurtle, and later the problem of letter case would raise its ugly head again.

Cerberus Alpha: Remastering the OS to Load the Program on Boot (Part 1)

Building a new iso for TinyCore was really easy enough, so the first thing I experimented with was adjusting boot behavior to what I wanted. The default option that I wanted was that Tiny Core would boot directly into a root command line interview. This is done using the boot code tinycore superuser. In ezremaster I made the mistake of entering only "superuser" instead of the whole phrase. With that fixed and the boot behavior working as desired, I set out to have the program run automatically. This proved quite the challenge.

When ezremaster creates the new OS for the .iso, it builds the actual folders that will go into the iso into a directory called "extract." Inside this is the actual system folders that will be extracted when the iso boots, such as /opt /etc and so on. What I did at first was to copy cerba.sh into the /extract/opt and modify bootlocal.sh with a line to start the script. Although later on I would need to start the script later in the boot process, this was not a problem yet. Modifying things this way caused the iso that was created to be "corrupt" and it would not boot at all.

Earlier in the project I had been able to modify the boot options by opening the iso and changing /boot/isolinux/isolinux,cfg, so I tried editing files inside the already built iso and rebuilding it with MagicISO. Specifically I went into /boot/core.gz/core.cpio where /opt is located. This idea didn't completely break the iso, but on boot I would get the errors "/boot/core.gz not found" (when core.gz was not named perfectly) or an error stating that there was a kernel panic.

After much searching I never found information on how to do what I wanted correctly. Fortunately, I eventually found the solution in ezremaster. In ezremaster there is an option to integrate backed up user data into the iso. Originally I didn't think this would work, but when I tried using this it did actually work. Here are the steps I had to follow to use this feature correctly to produce the iso with both the custom /opt data and :

Place cerba.sh in /opt of the running system

• Edit /opt/bootlocal.sh to start /opt/cerba.sh (*)
• In TinyCore's Control Panel, backup /opt/ as mydata.tgz somewhere
• Use /mnt/sr0 (mounted CD) as base iso
• Load mydata.tgz into ezremaster
• Load extensions using "Extract TCZ in to initrd" option and "Run TCZ startup scripts in chroot now"
• bash
• nano
• ncurses-utils
• ntfs-3g (*)
• Build the iso

* Later the correct place to boot from would be /etc/profile.d/cerba.sh and ntfs-3g was discovered to be needed

With all this work done, I finally had a working iso and it was correctly running cerba.sh from bootlocal.sh. Unfortunately, as it turns out, this was far too early in the boot sequence.

Cerberus Alpha: Tuning the OS for the Program

By now (version 0.B perhaps?) I had a mostly functioning program and it was time to set to work implementing it into the boot sequence. I implemented a function to try to mount all hard drives (still needs work, more on that later) and turned the main menu into a function of its own. Everything was not working correctly yet and one of the first problems was that the Bourne Shell (#!/bin/sh) was not correctly interpreting the script. Since this script was written to be interpreted by Bash I changed the 1st line to #!/bin/bash. I then had to install the bash interpreter itself and from then on it worked. Fortunately, Tiny core has a very simple and easy way to install programs from the desktop. As a result of installing bash, ncurses was also installed as a dependency which I like because I'm a fairly big fan of ncurses based programs (wavemon and nano to name a couple). Speaking of nano, that was the next thing that I installed. Personally, I can't really stand vi. In my opinion, nano is much easier to use and I like emacs too. I know some people really love vi and vim, so don't let me stop you. I wouldn't really need a text editor in the final version, but since I was still working on it I decided to leave it in. It doesn't add a lot of time to the boot process or the .iso size, so I think I will leave it in permanently in case anyone using the CD could use a text editor. A good text editor. Oddly, there was a single command in my script that was giving the interpreter trouble still, tput. I was using tput to print out a warning in reverse-red text, but it was giving me an error. It turns out that for tput to function it requires ncurses-utils to be installed. Well, ncurses-utils is not very large and it looks like practically the only thing it does is for tput, so I installed it. I ended up taking out this warning later so I may actually get rid of ncurses-utils altogether, but for now it stays in. At this point I'd like to mention that I had to install ezremaster in order to remaster the OS. Technically I didn't need it to do the remaster, but it was a great deal of help. Actually, whoever created ezremaster should really be commended. Once I understood how to use it correctly, it actually made remastering an EZ and painless task. I did not leave it installed in the final .iso, because there is no need for it. Around this time I started working on actually getting the program to run at the correct time, which I eventually did, but much later on I ran into another problem which called for a new program to be installed. When I had everything working perfectly, or so I thought, I burned the .iso to a CD and gave it a shot in a PC at home. It came back with errors telling me the file system was read only. After much investigating, I discovered that TinyCore does not support writing to NTFS file systems out of the box. I guess I must be spoiled by working with such "bloated" Linux distros as Slitaz and Lucid Puppy. Anyway, I found that the program I needed was ntfs-3g. With this installed, it was working well again. One cause of the problem was that I mistakenly formatted my 3 hard drives (in VMWare) as FAT32 instead of NTFS.

Cerberus Alpha: Tuning the program for the OS

The first challenge that I ran into was with the nifty little line drawing characters that I used to make the menu boxes look nice. Writing the program for the first time I copied the box drawing characters off of the wikipedia page about them. This worked fine in testing, but when running the program for the first time in Tiny Core the boxes looked like fuzz and when editing the program it was like garbled text. It turns out that the terminal emulator (aterm) that runs from the desktop in Tiny Core does not support the UTF-8 characters I was using. I found a workaround that looks like this:

echo -e "\e(0lqqqqqqqqqqq\e(BMenu:\e(0qqqqqqqqqqqqqqqqk\e(B"
echo -e "\e(0x\e(B Enter 1: Simple Install        \e(0x\e(B"
echo -e "\e(0x\e(B Enter 2: Full Install          \e(0x\e(B"
echo -e "\e(0x\e(B Enter 3: Simple Uninstall      \e(0x\e(B"
echo -e "\e(0x\e(B Enter 4: Thorough Uninstall    \e(0x\e(B"
echo -e "\e(0x\e(B Enter q: to quit to terminal   \e(0x\e(B"
echo -e "\e(0x\e(B Enter r: to reboot             \e(0x\e(B"
echo -e "\e(0mqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqj\e(B"

Although it looks a bit like crap in the code, it did actually render very well when running. It uses the escape character \e(0 to begin inputting text in alternate characters and \e(B to end this input mode. This change worked for the terminal emulator aterm, but later on when I was running the program from the command line without X the problem reared its ugly head again. I reverted the menu section code back to what it was originally (actually I rewrote it a bit more carefully) and once again it gave the desired printout. Technically, if you rerun the program from aterm it will still give ugly looking output. Hopefully at some point I will get around to writing a check for what environment the program is running from to fix this issue. Here is what the menu looks like, at least when it works right:

┌───────────Menu:────────────────┐
│ Enter 1: Simple Install        │
│ Enter 2: Full Install          │
│ Enter 3: Simple Uninstall      │
│ Enter 4: Thorough Uninstall    │
│ Enter 5: Replace sethc instead │
│ Enter q: to quit to terminal   │
│ Enter r: to reboot             │
└────────────────────────────────┘

You might by now notice the "replace sethc instead" option in the program has no "uninstall" function. This was intended for Windows XP as an alternate method. It works, but there are already much better programs out there designed to do the same thing for XP. It could be used as a last resort for Windows 8 too though, so I will try to get around to adding the option to undo it.

HP 8116A Review

Last week I reviewed the HP 8904A and this week I am reviewing the HP 8116A that I got with it. There is a bit more information out there regarding this model, but I felt like I would give my opinion on it anyway.

The front panel above is darker and not like any other test equipment that I have. It may be similar to other HP equipment of the same vintage, but I haven't seen any examples myself. Four main controls for settings are large rocker switches. The left three control the displayed digits (up / down) while the fourth controls "range" (essentially orders of magnitude). I think these buttons are quite neat and they are very intuitive and fast to use. One minor drawback is that there is no way to direct input a particular setting, but I don't think there are enough digits for that to really be a frustration. Also, if these keys were below the individual digits it would be just a little clearer what digit you are changing. Buttons under the LED display select what parameter you are adjusting.

The first thing that is immediately striking that I noticed about the HP 8116A is the absolutely gorgeous board inside the unit. Before I even opened the case I saw the thick golden traces shining through the vent holes in the bottom.

What a thing of beauty. You can see on the bottom of the lower board that there are plenty of nice big traces that are gold plated. I'm not sure whether the traces are exposed (no solder mask) and got plated during an immersion process or if they were plated and then coated with a very thin solder mask. Consider that a missed opportunity that I didn't get out my DMM and test the continuity to find out. It is certainly unusual to see a board like this that is not part of an RF section now.

Below is the top board which also has gold traces. It seems that it may have some interior layers. The layout and routing is very professional and most likely done with computer aid. I have not taken the time to catalog all the ICs, but I would guess were may be looking at a processor, some RAM and other peripherals. Although it might be the front panel controller as well since the ribbon cable goes directly to the front panel and the generator circuitry is likely to be on the bottom board.

Performance-wise the HP 8116A is presented as a 0-50MHz function generator. It can produce sine, triangle, square and pulses and can modulate its output as AM, FM or PWM. It also has some nice trigger and gating options as well as the ability to be used as a VCO.

As the modulation was one of the main features I was interested in using it for, I was happy that it produces a nice clean modulation throughout its range up to 50MHz. It produced 100% with a 5 V (amplitude) 10 kHz signal (above) and will go beyond 100% modulation if you want it to. That was a source of some confusion as the manual states that 100% modulation should be achieved at 5 Volt amplitude (the setting was 2.5 V amp.), but I believe that comes from the fact that the HP 8904A I was using as a modulating signal produces 5 V amplitude terminated into 50 ohms, but 5 V peak when terminated into high impedance. It should also be able to produce DSBSC with +2.5 V / -7.5 V modulating signal, but I was not able to produce enough DC offset for this with the HP 8904A.

As far as frequency accuracy goes, I think it is "pretty good" although it requires a fair bit of warmup time (typical for test equipment of this vintage). To be fair, I don't know whether the HP 8116A or my spectrum analyzer is out of calibration, but I think its accuracy is good without being necessarily absolutely precise. It seems to be off by about the same value so it may just need a calibration.

Its spectral performance is good and going through various wave shapes and looking at their spectra works out like an exercise in academic procedure. All the harmonics are where you'd expect them for sine, square, triangle and so on.

Above you can see a large amount of ringing in the scope shots, this is due to the lack of a good 50-ohm  termination on the oscilloscope and not indicative of the actual function generator performance. In my opinion it has very good performance, even producing square waves, well up into its operating range as shown below.

50 kHz square wave (left), 25 MHz square wave (right)

The HP 8116A can produce its waveforms with some fair DC offset and (using the duty cycle setting) can produce skewed triangle or sine waveforms (not necessarily a common feature with modern function generators). Below is an example of using the gate input to produce "bursts" of 50 MHz sine wave.

Below are some examples of the unit performing FM modulation that I could not find a place to fit anywhere else. It seems to be very stable, but I am not sure how to judge the "quality" of its FM modulation. I also tested the PWM and VCO functions and they worked well, but do not make for very interesting pictures.

Taken all together, I am very pleased with its performance. It doesn't have the convenience of a modern instrument or the ability to produce arbitrary waveforms. With a calibration, though, I think it would still contend as a useful piece to have around and I am certainly happy to have found it.

Choosing an OS to run Cerberus Alpha

In case you haven't figured out by now, part of the reason I'm doing this "write up" is because I want to be able to recall it later in case I want to do it again, or use the same method. After having built the main menu, I began to write the reboot and install functions. These would be changed too many times to count, but their form and function was essentially the same. Testing on my "Raspberry Pi" eventually got to the point where I needed to test the script in more of a live environment rather than the development space I was using. Very early on in the project, I thought that I would try making an MSDOS boot CD, based on a tutorial I read online. I abandoned this idea pretty early on as I realized that I'm not very skilled in writing programs for DOS and because it may actually pose a problem to get access to the target system due to some security features. My next idea was to build a script that would run directly from ISOLINUX. I don't know what I was thinking really. ISOLINUX is a boot loader. So after that stupid idea I set out to find a suitable OS. Extremely fast boot was the main consideration for what OS to use for my Live CD. The four main Linux distributions that I considered were Slitaz, Puppy Linux, Damn Small Linux and Tiny Core Linux. I've done a lot of fun stuff using Puppy Linux and it runs very well from a boot CD, but it loads its whole OS into memory and I decided it was too slow on boot for this application. Slitaz is generally very fast to boot, but I felt it still had more stuff than I needed. Tiny Core Linux is what I decided on, as I watched some videos and it seemed to boot extremely fast. Combined with a boot image that is around 14 MB I felt Tiny Core would be a very good way to go. It also loads into memory, but with such a small OS to load, it does not take very long. Damn Small Linux is something that I never got a chance to try, but I may come back to it some time. I installed VMWare on my computer and got to work testing the script in Tiny Core. Right from the get-go, it was obvious that I would need to make changes to the script for it to fit into Tiny Core, but that will be for the next post!

HP 8904A Review

I recently acquired two new function generators, one being the HP 8904A. As there is not a lot of consumer information on the net regarding the HP 8904A, at least that I could find, I thought it would be reasonable to start with that.

There are several options available for this unit and Option 001 provides 3 additional "internal channels" - B, C and D - that can modulate or sum with eachother to create unique outputs. For example, here Channel B is a 10 kHz sine wave which modulates Channel A - a 100 kHz sine wave - to output an AM signal (top).

Option 002 provides a second output which you can pipe your various channels out to. Only output one can be modulated, but you can "sum" signals to output 2 (bottom trace, above). I believe that adding option 002 adds at least a second channel as it would be useless without it. Looking inside you can see that option 002 actually requires a second board and so is not actually a software option.

As a stock unit the HP 8904A does not seem very impressive in my opinion. Without any options it is merely a 0-600kHz sine or 0-50kHz square, ramp and triangle generator. The floating output is a major feature, but if it's not something you need then a stock HP 8904A really does look rather ho-hum. My one major complaint though, is that it is not able to generate a square wave with any duty cycle other than 50% with a single channel. You must sum two channels and vary their phase to create a non-50% duty cycle. Fortunately my unit has both options 001 and 002.

Above is an image of an AD565AJD chip on one of the output boards, it is a 12-bit D/A converter and I think it is reasonable to assume that it is one of the major work-horses in the function generator. I really love these ceramic / gold packages, just because they look so cool! Below is a picture of the top board. I haven't gone through all the ICs, but I would guess mostly processor and ram stuff.

There is a lithium battery here, most likely used to store settings and operating state in RAM. It seems to be working as my settings have been retained although irritatingly a "special" function had to be changed so that it would power on to the last used state. It seems the battery may have leaked so I may replace it and clean the board.

Overall I'm very happy with my HP 8904A. I don't think I would have gone for it without any options, and especially not at the original price, but with the options 001 and 002 it is a very capable unit. Major drawbacks are the RAM based memory and lack of single channel duty cycle. The only other complaint I have with it is that it is very "menu driven" and can be tedious and non-intuitive to set up exactly the signal you want. I wouldn't want to use it for example to make a bode-plot necessarily, but again all in all I think it is a very niece piece of test equipment.

For more information you can Google search: Keysight 8904A to find their scans of the original documentation (Keysight is formerly Agilent is formerly HP aka Hewlett-Packard).

New Function Generators

I got a pair of new function generators this weekend. I'll try to post some pictures and maybe review of them. Here's a preview picture:

HP 8116A on the left and HP 8904A on the right.

Building Main Menu and Accessing Mount Points

The main menu was written using a case style set of arguments for what the user would input, but I had to ask online how to have it default to an option on its own after 10 seconds. It turns out that the read command to accept user input has that option in-built, so it was very simple. It's not 100% as nice as I'd like it, so I may someday take the time to rewrite it to use a ncurses "dialog" box instead, but for now it functions just fine. The actual graphics of the menu became a problem later on, but that will be for another post.

One desired feature of the program was that it would have the options to either assume the target hard drive would be in a certain place and attempt the changes or to find all accessible drives and mount them and make changes to all of them. Once again, searching the internet and asking for help provided the commands I needed. It turns out that using 'awk' to choose out a pattern something like /dev/sd[a-z][0-9]/ and then { print $6 } was the way to select only the 6th column of any line containing the pattern.

Integrating this into a while loop was also something that I needed help with since I didn't know about <( functionality in bash scripts. So what I had at the end was something like

while read mPoint
do
#stuff
done < <(df -P | awk '/Sda[a-z][0-9]/ { print $6 })

Which would take the output of all the commands in parenthesis (find all mounted partitions, then choose out the patterns and print only column 6) and load the "answer" into the variablemPoint. Then I could do things with $mPoint inside the while loop. This technique would be used again later to mount all drives, but I may still change that.

Cerberus Alpha - About the Project

I wrote "Cerberus Alpha" because a friend brought me her laptop to fix after she had forgotten her Windows 8 password. Since Windows 8 was very new at the time there was little information on breaking into it. I found out that the exploit of replacing sethc.exe or utilman.exe with cmd.exe still works in Windows 8. After I helped her I thought it would be handy to have a tool to do that for you and that is simply what Cerberus Alpha is designed to do. It is a boot CD by necessity and I chose TinyCore Linux as the base OS.

This series documents my struggles of writing the program, developing the custom OS and testing.

Following is a cut-out of the about page that the program will print if you enter 'a' at the main menu:

┌───────────────────────   ABOUT CERBERUS ALPHA   ─────────────────────────────┐
│ Cerberus Alpha                                                               │
│ version 1.1 - Thursday, Dec. 5, 2013 8:31 PM local time                      │
│ Created by ThreeNine --> threenine @ gmail . com                             │
│ Feel free to write me an email, but it may take me a while to reply          │
│ Put Cerberus Alpha in the subject!                                           │
│ I hope you enjoy and only use it for good not evil! ;)                       │
├───────────────────────   WHAT DOES IT DO?   ─────────────────────────────────┤
│ Cerberus Alpha is a script designed to launch from a linux OS and access     │
│ Windows files systems, then replace utilman.exe with cmd.exe, and back it up.│
│ There is also a mode to replace sethc.exe with cmd.exe                       │
├───────────────────────   WHY DOES IT DO THIS?   ─────────────────────────────┤
│ Replacing utilman with cmd is a way to exploit a security vulnerability in   │
│ Windows, allowing us to get a command prompt by pressing win+U (or shift x 5)│
├───────────────────────   WHY DID YOU MAKE THIS?   ───────────────────────────┤
│ I had a friend who forgot her password to a Windows 8 Laptop.                │
│ There are utilities to change passwords on older systems, but the only way I │
│ could find to fix her password was to use this exploit!                      │
│ This is what inspired me to write this script and create this CD             │
├───────────────────────   ABOUT THE CD   ─────────────────────────────────────┤
│ I also created a Boot CD to run this program from, to make it run almost     │
│ automatically. The CD runs a version of Tiny Core Linux that I specifically  │
│ modified. You have the option to boot into the standard OS during startup    │
└──────────────────────────────────────────────────────────────────────────────┘

There are some other hidden menu options, mostly for fun or testing. I will remove testing features when I publish the program. I guess you could say this is an "open source" project since I will be publishing the source code. About the email - it's not my normal email address, but I decided to use an alternate since I didn't want to get spammed by posting the source code online.

Hello World!

Hi everyone! I thought I would go ahead and take a crack at writing a blog and seeing how it goes. I've written a blog before, but it was hosted on my personal website and got zero traffic. So here I am! I think it will mostly be about electronics, test equipment, engineering and programming, but I might also post about random stuff like snakes!

My first feature is going to be about my experience programming a utility that is used to bypass Windows 8 security. I want to be open about this, so I'll tell you now that I will be taking this information from my old blog on my personal website and posting it about once a week. I think it will make for a good introduction and hopefully after that I will get started on a new project.

In the mean time I will try to do some test equipment pictures and maybe reviews. Here's a preview picture from my HP 3585A Spectrum Analyzer to give you an idea of what this blog is about:




Follow my blog with Bloglovin