ECE101 – Basic Electrical and Computer Engineering

Brainstorming for a project has always been difficult for me.  There’s the saying, “If all you have is a hammer, everything looks like a nail.” I always try and solve a problem with the tools I already have, not wanting to spread out and learn different techniques. Or I’ll get focused on one particular technology I want to learn so I’ll try to use it to solve a problem and miss an obviously and drastically superior solution. I have to think, this project isn’t entirely about me. Obviously, we don’t want to go too far the other direction, but… I think you see my dilemma.

Using the situation discussed in my last post, and discussing more specifically the requirements of the “customer” (Mike), I broke the project down into different parts.

Power Source
Theft Detection
Locator
Mike Detection
Theft Notification

These topics tend to overlap and mix or aren’t needed, depending on the approach we decide to use.

Power Source:
AA or AAA’s
Coin cell
Li-ion / Li-pol

The real question was: Rechargeable versus replaceable. Replaceable would be easiest to design but would require fairly easy access to the batteries, whereas we’re hoping that the great majority of the alarm is hidden inside the boot and inaccessible to potential wrongdoers. Because of this, and that I happened to have a couple on hand, we decided to go with a Li-pol.

Theft Detection:
Vibration sensor to detect motion.
Accelerometer to detect motion.
Some form of alarm when Mike and the boot get too far apart, not based on vibration.
GPS with a set (or setable) area that will send a notification if that area is left.
Theremin circuit on the handle.

I immediately nixed the GPS idea due to cost, size, accuracy, difficulty of design, and reception indoors. This will be mostly used indoors and if it makes it outdoors, we’ll probably have lost our possibility of recovering the boot. The Theremin circuit was enticing due to its retro electrical style but, depending on the sensitivity, would either make noise when people are just around it or allow people to carry the boot by the soles. Also, with the proximity alarm, I struggled thinking of a way that I could set a distance accurately and not have a false positive. False positives would actually be worse than false negatives, if we tick off the higher-ups. And since accelerometers are more complicated and sometimes more expensive than normal vibration sensors while achieving the same goal, we ended up deciding on the vibration sensor. This may change if the vibration sensor is too sensitive.

Locator:
GPS/GSM locator to broadcast its location to make it easier to find, in case the boot is successfully stolen.
GPS/WiFi so we wouldn’t have to pay for data packets on the cell
Some form of hot/cold locator.

We decided to not have a locator, mostly for the sake of simplicity.

Mike Detection:
RFID for Mike Detection, wireless for communication.
Wireless for both, low power for detection, high power for communication.
Car key fob style arm/disarm
Semi-secret switch on the boot to override alert.
Fingerprint scanner
Other biometric scanner
Keypad with unique passcode

This was a big issue for me and was difficult for me to decide. After discussion with some of the other junior guys, we decided on the car key fob style arm/disarm. After coming to grips with the limits of passive RFID, I decided that wasn’t the way to go. Then, as a selling point, Brian (a LTjg) explained it somewhat like this, “You can waltz in the room, put the boot on the table, hit the key fob and have the boot make the ‘Buh-bweep!’ sound. That’ll get their attention.” Up until he mentioned that, I was imagining this to be a surreptitious alarm, not to let the people know it was there until the first time it went off. But, he’s got a point. That is pretty stinking cool. As an added bonus, someone mentioned putting LEDs into the bottom two eyelets of the boot and having them flash like a cars headlights. Genius, I say. Pure genius.

Theft Notification:
Key fob in Mike’s pocket to warn him, either through vibration or an
audible alert.
Have an audible alarm on the boot that goes off when someone steals it.
Have a cell unit that calls his phone to tell him when it’s been stolen.

If we’re using the car alarm style, we’ll need a car alarm sound to go off when the boot is triggered. Thus, we decided on the audible alarm / lights flashing method.

Summation:
Reviewing this brainstorming session and gaining a sense of what this project entails, I think I’m most concerned with the sound. I’ve never made sound before and my Googling has yielded mixed results. And my attempts to create sound by simply varying the frequency of a square wave sent out to a speaker made pitch accurate, yet completely unusable sounds.

Also, in order to use what’s on hand, I’m pretty sure I’m going to be using a PIC16F877A.

Let me know what you think! Leave your thoughts and comments below.

Here’s a video introduction. I’m not used to being on camera, so be gentle.

As you’ve read in the “About” page (I know that’s the first thing you did when you got to the page), I just recently joined the US Navy.  As with other navies in the world, we have our share of odd customs and the Seabees are no exception. If you are the junior Ensign in a Seabee command, you become “The Boot Ensign” or just “The Boot”. The Boot has the illustrious job of doing all the odd jobs that nobody else wants to do, being subject to ridicule, and carrying around a black boot filled with concrete to all command social functions. I am not the boot Ensign. I’m actually the senior Ensign, called “The Bull Ensign” and technically it is my responsibility to make sure all the other Ensigns in the command are squared away and doing what they’re supposed to. I say technically because in reality, there’s only two Ensigns, Mike and me, and since we entered and graduated OCS together, I’m only considered senior because my last name starts “Bi” and his starts with “Bo”. It took us awhile to come to that conclusion.

One of the joys of being The Boot Ensign is that other people are actively trying to steal the boot. The rule is that the boot can be stolen whenever the boot is left unattended, but force is not permitted. If the boot is stolen, whoever stole it is only limited by their imagination in what terrible and/or embarrassing tasks must be done in order to earn the boot back.

It is my goal to create some sort of Boot Alarm so that people cannot steal the boot without us knowing it. I want something simple and easy to use, small, hard to circumvent, and cheap. In the process of designing and building this, I will keep you posted with everything I learn, and hope you’ll leave tips and feedback when you see a better way to do things. At this point, I’m still not sure where we’re going to head with this. I’m trying to keep an open mind to make sure I don’t reject better ideas out of hand.

I hope this turns out to be a learning experience for all of us and look forward to the challenges that will be presented in creating the best Boot Alarm in the world. Being the only Boot Alarm in the world, I most certainly hope it merits that title.

Hi everybody. This is my first post of a series related to assembly programming for PIC Microcontrollers. In this first tutorial I will show you how to set-up the compilers and IDEs that you will use for building code in assembly.

We will start with installing the tools for Linux based operating systems. I am using Ubuntu operating system which is free for download. For writing assembly code I am using Piklab, also a free program. To install this on Ubuntu you have to open the terminal and type the following command :

sudo apt-get install piklab

You will be prompted for you root password. Type it in to install the software. After installation, to launch the program you open the terminal and type “piklab”.

This is the Piklab main window. You are also going to need “gputils” for compiling the source code into hex files. To install gputils you type the following command into the terminal :

sudo apt-get install gputils

So now we have the software needed to write programs in assembly and compile them. We have to do one more thing. Open Piklab and select from the menu “Settings” -> “Configure Piklab” -> “Standalone file” -> “Toolchain” -> “GPUtils”. Now we have configured Piklab to use gputils as assembly tools for files that are not included in any projects. We are going to use this method for the first few codes.

If you are using Windows OS, Microchip is offering for free the MPLAB IDE that can be downloaded from their website. It is very easy to install and setup. You just follow the steps after running the setup.exe file.

Thanks for reading. I will soon post the first assembly lesson. If you have any questions just leave a message.

There is a special location set aside on PIC microcontrollers called the ID location that is used for either storing checksum or identification purposes of the PIC.  It has four location spaces, but only the 7 least significant spaces are used.  The different applications of this space is limited only by your imagination.  For my applications, this area has been most useful in holding the version number of the software on a PIC.  As I improve my projects and the firmware on them, I lose track of which board contains which version. Of course, you can use it for whatever purpose you need.

Using this space is straightforward.  Simply use the following code, putting whatever numbers in there you’d like.

__IDLOC(0741);

If you have any further questions, feel free to e-mail me or post a comment.

When writing programs for the PIC, there are certain things that you will want to do that aren’t specific to one particular project.  The functions written to perform these tasks might also be rather large and make the main function longer than desired.  Or perhaps the function is specific to this project but makes the main function too cluttered.  Or perhaps there are a collection of related functions that would best be grouped together.  Whatever reason you may have for storing a function outside of main.c you can do it by linking the files.

You will need to create a c file in which to place the function, named in a way that works best for your situation.  Something descriptive of what the function does would be best.  This file will need all the normal appropriate headers, such as htc.c and/or stdio.c.  Besides these files, you will need to link to another header file that you will make.  The creation of the header file will be covered later, but the formatting for the header is

#include

#include "wait.h"

Note the use of quotations instead of brackets.

Now, in the file itself the code will be placed just like any normal function. Below is a sample of a dummy wait function as it were to appear in it’s own file.

#include
#include "wait.h"

void wait(unsigned int time) {
int count;
for (count = 0; count < time; count++;> continue;
}


If this is saved without first creating the header file, it will create an error. Do not worry about this until you’re finished with everything.

The header file is quite simple. For the example above, the header file in its entirety would be as follows:

#ifndef WAIT_H_
#define WAIT_H_

void wait(unsigned int time);

The first three lines are inserted by Hi-Tide upon creation of the h file. If more than one function is defined in the c file, each function needs its own lines with the correct parameters.

In order to use the functions in the main c file, simply include the link to the header file at the top of your program. They can then be used as if they were attached at the bottom or top of the file.

Most of the errors I encounter involve forgetting to put the proper headers on the files or not changing the h file after changing the function or adding a function to the c file. If you run into an error involved with the functions in these separate files, check those two points first.

I mentioned sprintf() briefly in my post about communicating between your PIC and the computer but have since learned a couple things I think others could benefit from. So this is going to be a kinda hodge-podge post.

First, I threw together a quick function that will take any number, convert it to ASCII, and then send it out to the computer. It’s not fancy, like most of my programming, but it is functional if you just want an idea of where to start.


void transmit_comp(volatile unsigned int a) {
unsigned int i;
unsigned char a_ASCII[4];

sprintf(a_ASCII,"%d",a); // Convert it to ASCII

void transmit(volatile unsigned int a) {
TXEN = 1; // Transmit enabled
TXREG = a; // Transmitting the requested character.
while (!TRMT) continue;
TXEN = 0;
return;
}


You are limited to printing out as many numbers (or characters) as the value of i in the above code. Setting i to a large number has no noticeable effect when looking at it in your console but it has two downsides. It uses up data space on your PIC and also each of those blank characters have to be transmitted, taking time. So be wise in your selection of i.

One obvious thing about the code above is that it only prints out integers. So what about longs and floats? What can we do? sprintf() is designed to be able to handle floats, doubles, and longs. However, what about those of us using the free compiler, either the PICC-lite or its replacement, the HI-TECH C PRO for the PIC10/12/16 MCU Family (whew! long name)? We are out of luck.

For some reason, any attempts to sprintf a float, it outputs the ASCII character “f”. I honestly don’t know why. This occurs in both compilers.

If you’re still using the PICC-lite, you can go to Properties->C/C++ Build->Tool Setting->Linker->Printf and set it so that it prints integers, longs, and floats. Doing this can create a new error saying that you need a library called “pcl40c-f.lib”. I never could find this file. This error will disappear if you switch to the newer HI-TECH C PRO compiler, but you will still only be creating the letter “f” as an output.

While I’m not positive, I believe this only applies to the smaller PICs. 18 series and above should be able to output floats.

Not a lot of help, but hopefully this will at least save time tearing your hair and trying to figure out why it’s not working.

Voltage Follower

The Basics

The voltage follower, like the comparator, requires no components other than the op-amp itself.  The voltage follower is typically used as a buffer; whatever circuit is connected to the output will have essentially no effect on the circuit attached to the input.  Either of the inputs is connected directly to the output.  The other is connected to the part of the circuit where you would like to monitor the voltage (see the schematic and simulation below).

Schematic:

Simulations:

Sweeping Vin

Gain Derivation (sort of)

There isn’t really a gain derivation.  Just remember, the output equals the input just as the name suggests (and also the reason there is only one trace visible in the sim).

Comparator

The Basics

The comparator, unlike the previous amplifiers I’ve covered, requires no components other than the op-amp itself.  The inverting and non-inverting inputs are used to compare two voltages.  The higher of the two inputs will drive the output to the corresponding supply rail.  For example, if the voltage applied to the non-inverting input is higher than the voltage at the inverting input, the output will be whatever voltage is applied to the positive supply rail of the op-amp.  I think the figures below are the easiest way to understand the comparator operation.  Also, because of the simple nature of this amplifier topology, I pared this post down to the basics.

Schematic:

Simulations:

Gain Derivation (sort of)

There isn’t really a gain derivation.  Just remember, the output will go to the supply rail of the highest input: the negative rail for the inverting input and the positive rail for the non-inverting input.