Annoying Beeping Prank Circuit

Since i quit my old job last week, and I had the last day more or less alone in the office, I made a few loving pranks on my coworkers. One of them was a simple circuit based on a 555 timer. The circuit is simply a pulse oscillator with a couple of minutes between pulses. The circuit is seen here:

556 Pulse oscillator

The 1M Ohm resistor sets outputs high time together with the capacitor. The 100 Ohm resistor and capacitor sets the low time. This setup gives the inverse output of what I wanted to drive the buzzer (should be any buzzer with internal oscillator that can be driven by 9V), but it needed to be that way to keep power consumption low. If the resistors where swapped, the DIS-pin would discharge the power rail through the 100 Ohm resistor instead of the capacitor. To invert the output i used a second 555 as an inverter. In this configuration the circuit drew 8mA, which would give a couple of days use with a 9V, 580mAh battery.
Google told  me there was a CMOS-based low power version of the chip, TLC556. That chip was pin compatible and used up 0.3mA. This gave a run time of about 80 days which I was very happy with.
The circuit simply gave a short, loud beep every few minutes. I hid it in my colleagues flower pot and it took him quite a while to find it.. ;)

Implemented circuit

MIDI2VC+, a MIDI driven Voltage Controller

The MIDI2VC+, v2, is finally finished. These are the implemented features:

MIDI2VC+, v2, primary side.

MIDI2VC+, v2, secondary side.

• 5 octaves 1V/octave VC output
• 3V gate output
• Low note priority
• Filters channel number, plays any MIDI-note regardless of channel
• MIDI input and USB-MIDI input. Prioritise USB if both are connected.
• Reset button
• Pitch bend, 2 semitones in each direction
• Input voltage 8-35V (high input voltage may need heat sink on regulators)
• 5us trigger output
• Powers USB-keyboard
• USB interface tested on Korg MicroKEY 25
• RCA jacks as outputs. Used RCA wires are easy to find very cheap, and jacks can easily be salvaged from scrapped audio equipment.
• Both code and hardware is open source licensed to CERN OHL v.1.2.

The PCB needs two straps. The MIDI input to the micro controller has no connection. Pin 4 on the optocoupler needs to be strapped to pin 24 on the micro controller. Also, the optocoupler needs to be powered from the 3V3 rail instead of the 5V. Before the optocoupler is mounted, one needs to cut out pin 6 and the pad from the pull-up resistor right besides it. When the optocoupler is mounted, strap a wire from pin 6 to the 3V3 rail.

Cutout below optocoupler.

Anyone is welcome to edit the layout files to fix the straps. I'm not going to do another version of the PCB at the moment. Eagle files and source code is available here.

Tinker-Box á la Bob Pease

I made a tinker-box, as recommended by Bob Pease in Troubleshooting Analog Circuits. It's simply a box of banana jacks connected to various resistors and capacitors. There is one rotary switch connected to resistors of values 10-66kOhms. There is a second rotary switch connected to capacitors of values 10p-1uF. Finally there is also a 100k potentiometer and a ferrite bead. Not much else to say about it other than that it's of great use when experimenting with op-amps. I used it when  i built last posts EMC-meter.

Inside of tinker-box.

Panel-side of tinker-box.

EMC sound detector

I saw this youtube video a while ago. It shows an EMC meter using a piezoelectric summer, a coil and a fet.I thought that instead of  coil, I could do the same thing using a semi-rigid cable for a magnetic field probe, like the ones Doug Smith describes. I have previously written about a field probe that I have used with an oscilloscope. The signal from the probe that I have seen has been on the order of 10mV, max. This is far to low to make a summer sound. The summer needs a at least a few volts of signal to sound enough.
So to make this circuit work I needed to produce a gain of at least a few hundred. I started out trying to do this with an uA741. With a gain-bandwidth product of 1MHz, I could at most produce a gain of 100 at 10kHz, which was a bit weak. After that I tried using a . It had a better gain-bandwidth product of 3MHz, but I had a lot of problems with lock up and oscillations.
Finally I solved the gain-bandwidth issue using two op-amps, the LM358 (two amplifiers in one package).  Since the signal is low, and we are interested in the AC-signal, I AC-coupled the feedback loop in both amplifier stages. Final circuit looks like this:

EMC sound detector

EMC sound detector, actual build.

There was some trial and error and usage of what components was at hand. To determine the maximum gain of the second stage, I used a potentiometer where the 270 ohm resistor is now. I turned the potentiometer to just below the point where the circuit started to oscillate. The circuit is sensitive enough to sound out fields from, for example a cell phone, but the sound volume isn't that high. I think the circuit can achieve higher gain with a smaller cap on the output (22uF now). I would need to put a higher resistor after it though, to keep this stage from filtering out low, but audible frequencies.

New PCB's and Books

Got the new PCB's for the MIDI2VC+ v2 from OshPark yesterday. I'm pretty happy with how they look. I managed to cram in everything on the top layer. The bottom layer is only ground, not a single trace or component.

New PCB's from OshPark

Also, I got some nice books from dad for my birthday. It's:"Build your own transistor radios" by Ronald Quan and "Experimental methods in RF design" Wes Hayward et. al. These will most certainly give some nice ideas for electronics projects. I've already started reading Quan's book, and it's really interesting.

Some nice birthday books from dad

Velleman KSR6 kit, error in silkscren

Last post I talked about the KSR6 Velleman kit and that the robot didn't turn when closing in on objects. After troubleshooting the robot for a while, I finally found the error. The voltage divided node at U4 +in and U3 -in lay at nearly 6 volts, instead of the expected 3 volts (which in retrospect is odd, this voltage should instead be closer to 2V, only explanation I can come up with is that that R8 had a bad connection, but who knows?). This made the integrator U3 integrate only voltages over the node, which was almost nothing... After inspecting the schematics and the layout, it was obvious that the silkscreen component markings had mixed up R8 and R10. Switching them made the robot work the expected way.
This might not be true for all PCB versions. This PCB was marked 21-885. If you are uncertain, measure the voltage of pin 3 or 13 of IC1. It should be  close to 3V. If resistors are placed wrong, voltage will be closer to 6V.

Velleman Ladybug Robot, KSR6

My daughter got a Velleman KSR6 kit for Christmas, and the other day she finished it's assembly. We tested it out and it's motors ran as they should, but the robot didn't turn when closing in on objects. I sighed a bit and started troubleshooting. When looking into the design I started thinking it actually was quite cool. It's control system was made from four op-amps. No digital circuitry at all. I can't publish the whole schematic here, since it's copyright Vellemans, but it can be found in the manual in the above link. I made a simplified Spice simulation of the circuit and made some comparing measurements. I'll briefly explain what the different parts do and compare simulations to measurements:

Simplified LT-Spice schematic drawing

 U1

A pulse of about 1ms is fed through the DC-blocking C1. The pulse in the actual design comes from the IR-diode, which picks up reflected IR from the IR-LED.

U1 is simply a non-inverting amplifier which is AC-coupled using C2. C2 makes the gain roll of to unity at DC.

The big pulse is from the IR-LED, for triggering purposes. The small pulses are from the U1+ node, a high pass filtered pulse.

And the same filtered pulse in LT-spice. Very similar to reality. 

U1 amplifies the positive going pulse to look like this:

Amplified pulse, almost rails the output of U1.

Amplified pulse of U1, looks very similar when simulated.

U2

This is an emitter follower with a diode on the output and a bleeder resistor to ground. U2 can only source current to node U3+. After U3+ is charged,the voltage is kept high by C3 and R4 for a while.

The small pulse of node U3+ is not what we expect.

The simulation shows what I expected. A high step that slowly bleeds out through R4.

So the problem is probably in node U3+. Perhaps a bad connection to the cap or a bad cap. I'll look more into it. In the following sections I'll just explain what is supposed to happen and show the simulations.

U3

Is a slow integrator that keeps the output high while U3+ is discharging. If the original incoming pulse (at U1+) is smaller than some threshold, U3o won't have time to integrate to any significant level before U3+ is discharged. U3o then stays low.

U3o when it has had time to integrate to a high voltage level.

U4

This is a comparator. If U3o is over 3V, U4o drops to it's lowest level. If U3o is below 3V, U4o kicks up to it's max output. 

Complementary outputs of U3 and U4

U3 and U4 has complementary voltage levels at their outputs and the are used to drive the H-bridge to one of the robots motors, making the motor reverse for a while when the robot receives a big echo from it's IR-receiver. This makes the robot back out and spin 90 degrees before continuing forward.

MIDI2VC+, demo with low noise

Last post I wrote about the noise problems when running the MIDI2VC+ with a mock up synthesizer. I suspected that the I2C bus picked up noise and crosstalk from the USB bus, as they where routed very close each other. I also looked at emitted noise on the board and saw that there where lots of emissions at the USB connector. To see the emissions I used a looped semi-rigid coax with a slit. The coax was connected to a scope with a 50Ohm standard coax:

Electromagnetic emissions sniffer made from semi rigid cable

I captured  image on the scope showing background levels and levels from USB connector:

Background emissions vs USB connector emissions

I patched the board by cutting the I2C traces that passed the USB connector, soldered wires instead. This made the noise go away completely, as can be heard in the demo.

MIDI2VC+ board with I2C bus patched with white cables.

 The only problem left right now is that, from no known reason, the I2C transmission process stops prematurely, before it has completed. If I don't find the cause, I may add a time out and resend feature that may solve the problem.

MIDI2VC+, synth demo

I tried hooking up my MIDI2VC+ to the old bread boarded synthesizer and it sounded terrible. Basically you can hear a lot of noise that turns on exactly when the USB device is configured and data is transferred on the USB bus. The thing is, I was a bit foolish and routed the I2C-lines very close to the USB data lines. My bet is that crosstalk is leaking into the analogue parts through the I2C bus. I'll look into this and my first remedy will be to patch the I2C bus so it doesn't go so close to the USB bus,and perhaps also shielding it from the environment.

MIDI to VC conversion is working

I am now actually having a working path from USB to control voltage. I tried hooking it to my messy synthesizer,which doesn't seem to work. I then discovered that the converter only works if PicKit2 or the I2C analyzer is connected to it. My thought is that there is some issue with grounding in the board. I'll look into this. The actual working code and HEX is here. It still contains a lot of debug code though, and it doesn't sport all features yet...

I2C, UART and USB

I finally got all three interfaces working at the same time. While the PIC24FJ64GB004 hammers out I2C data, it configures and reports about an USB device! This is so cool, I took a not so cool screenshot:

All three interfaces used at the same time!

All that is left now is to write the algorithms for how to handle received data.

PIC24FJ64GB004 I2C setup

I've been working on the I2C-setup on the MIDI2VC+ for a couple of days. First off I soldered the DAC and accompanying components to the board. I have been a bit worried about the I2C bus since it is connected to both 5V and 3V3 interfaces. The PIC has 3.3V logic and the DAC 5V. The I2C bus runs on 5V and the PIC I2C pins can tolerate 5.5V, so I thought that it might work since both devices compatible logic levels.
Running an I2C-bus this way is out of spec and may mean that you cannot run it full speed. Some testing proved that it was possible to run the bus at 360MHz without errors. I used the Beagle I2C analyzer from TotalPhase, and it was really good for analyzing lots of I2C data to see how much errors there were in the transfers. I ended up running the bus at 100kHz, to save power and add robustness.
Since I didn't have a digital oscilloscope previously, I adopted an old Tektronix 4030 that was being scrapped at work. This must be one of the earliest generations of DSO's, the scope looks very similar to my Tek 4065. I did get it running the way I wanted it to, but it wasn't that user friendly. You had to go into a menu blip yourself to the "Normal" trigger mode, a function that usually have it's own front panel button on modern scopes...

Tektronix 4030 capture of I2C transmission. Data on top trace, clock on bottom trace.

//I2C setup:

    I2C1CON = 0x8000; //I2C module enabled
    I2C1BRG = 0x13c; //= (32000000/100000 - 32000000/10000000) - 1, 100kHz SCL 

//Function i2cTransmission
//Polls flag to see if there is I2C data to be sent and
//walks through the transmission process

uint16_t i2cTransmission(uint16_t i2cTransmitCycle, uint16_t *i2cstatus, uint16_t i2cData[]) {  
   //Polls transmit cycle flag, I2C interrupt flag and ACK-status  
   switch (i2cTransmitCycle) {  
     case 0:  
       if (*i2cstatus == 1) {  
         i2cTransmitCycle = 1;  
         I2C1CONbits.SEN = 1; //start condition  
       }  
       break;  
     case 1:  
       if (I2C1CONbits.SEN == 0) { //when start condition is complete, load slave address  
         IFS1bits.MI2C1IF = 0;  
         I2C1TRN = (0x60 << 1);//load DAC address  
         i2cTransmitCycle++;  
       }  
       break;  
     case 2:  
       //when address is ACKed:  
       if (IFS1bits.MI2C1IF == 1 && I2C1STATbits.ACKSTAT == 0) {  
         IFS1bits.MI2C1IF = 0;  
         I2C1TRN = i2cData[0]; //load first data byte  
         i2cTransmitCycle++;  
       }  
       break;  
     case 3:  
       if (IFS1bits.MI2C1IF == 1 && I2C1STATbits.ACKSTAT == 0) {  
         IFS1bits.MI2C1IF = 0;  
         I2C1TRN = i2cData[1]; //load second data byte  
         i2cTransmitCycle++;  
       }  
       break;  
     case 4:  
       if (IFS1bits.MI2C1IF == 1 && I2C1STATbits.ACKSTAT == 0) {  
         I2C1CONbits.PEN = 1; //stop condition  
         i2cTransmitCycle++;  
       }  
       break;  
     case 5:  
       if (I2C1CONbits.PEN == 0) { //when stop condition is finished, transfer is complete  
         i2cTransmitCycle = 0;  
         *i2cstatus = 0;  
       }  
       break;  
     default:  
       break;  
   }  
   return i2cTransmitCycle;  
 }  

Receiveing MIDI data!

Finally! I am receiving MIDI data from the keyboard! The data is piped to the UART after zero padding has been removed. This means that I can start reusing the functionality of the old MIDI2VC, to start converting received data to I2C (received by DAC).

Received MIDI data

USB reached configured state!

OK, I kind of gave up on extracting and reading all configuration data from the Microkey-25, so I cheated a bit and read the USB packets from Free Device Monitoring Studio. Anyway, I sent the SetConfiguration command to the Device, and lo and behold, the red LED  on the keyboard lit up. This must mean that the device is configured! Now all I need to do is start extracting data from the keyboard...

USB getConfigurationDescription

Let's continue by receiving the descriptor for configuration 1 (the only configuration supplied by the device)
4002 0105 0900 2002 0224 0604 0120 0130 0103 2409 0001 1001 4002 0324 0903 1001 0224 0600 2501 0001 2407 0000 0301 0200 0004 0932 8000 0101 0053 0209 

Byte	Field	Value	Meaning
0	bLength	0x09	The Configuration description consists of 9 bytes
1	bDescriptorType	0x02	Descriptor type CONFIGURATION
2-3	wTotalLength	0x0053	Total length of configuration, including descriptors for configuration, interfaces and endpoints
4	bNumInterfaces	0x01	Configuration has 1 interface
5	bConfigurationValue	0x01	The value of this configuration is 1
6	iConfiguration	0x00	String index 0 describes this configuration
7	bmAttributes	0x80	Device powered by bus and has no remote wake up feature
8	bMaxPower	0x32	Max power consumption is 50*2mA = 100mA

The rest of the supplied data should be descriptors for interfaces and endpoints:

Interface descriptor

This descriptor starts with byte 9 in the data above. The first value is the length of the descriptor, which we can see is 0x09. That means that the data to interpret is:

0000 0301 0200 0004 09

Byte	Field	Value	Meaning
0	bLength	0x09	The Interface description consists of 9 bytes
1	bDescriptorType	0x04	Descriptor type INTERFACE
2	bInterfaceNumber	0x00	Interface is number 0
3	bAlternateSetting	0x00	Value to select this alternate setting
4	bNumEndpoints	0x02	This interface uses two endpoints
5	bInterfaceClass	0x01	Interface class is 1
6	bInterfaceSubClass	0x03	Interface sub class is 3
7	bInterfaceProtocol	0x00	Device does not use class-specific protocol
8	iInterface	0x00	String index for this descriptor is 0

Now, the next entry puzzles me, descriptor is of type 0x24. I found this post, that explaines that this is a class specific interface descriptor. I'll have to look into this some more.

USB getDeviceDescriptor

In my last post I talked about making a successful USB transfer. It was a getDeviceDescriptor transfer, which transfers info about the device to the host. The transferred data was:0100 0201 0150 0121 0944 4000 0000 0110 0112
The data was received from the same Korg Microkey-25 as previously used.

Byte	Field	Value	Meaning
0	bLength	0x12	The Device description consists of 18 bytes
1	bDescriptorType	0x01	Descriptor type DEVICE
2-3	BCD	0x0110	USB Spec Release Number 1.10
4	Class	0x00,	No class per interface defined
5	SubClass	0x00	Must be 0, since Class code is 0
6	bDeviceProtocol	0x00	No class specific protocol used
7	bMaxPacketSize0	0x40	Max packet size 64 for endpoint 0
8-9	idVendor	0x0944	Korg
10-11	idProduct	0x0121
12-13	bcdDevice	0x0150	Device release number 1.50
14	iManufacturer	0x01	Index of string descriptor describing manufacturer
15	iProduct	0x02	Index of string descriptor describing product
16	iSerialNumber	0x00	Index of string descriptor describing serial number
17	bNumConfigurations	0x01	Device has only one configuration

So all of this looks fine to me. Apart from this, I have also addressed the device, which should mean that I only need to set the device configuration to get the Microkey up and going. I do need to spend some time on the code though, I can't keep hard coding all this stuff, I will need some level of abstraction, even though I'd prefer to keep things as simple as possible...