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.