I bought a new scope, Tektronix TDS1002. It's an absolutely lovely instrument! The feelings I can only compare to are what I felt when I bought my first scope: it's a completely new world. Thanks to it, I can now see many problems that I wasn't aware of before. I already fixed some, some are sorted out as not dramatic.

Anyway, the updated schematic of Hetski is in there, just in case. Most significant fix is converting 25MHz distribution into a sort of transmission line, terminated at far end. The need for extra power filtering also has become evident.

It's been a while since the last time I posted.

Most of the time I was busy building a radio clock receiver. First version, a direct amplification VLF receiver, kind of worked and I even managed to decode the signal in ATmega8, but reception is very poor. There are problems with selectivity and it's barely possible to amplify signal without amplifying all of the terrible noise that loves to dwell in VLF range.

Current project is Superhet VLF receiver. So far so good, the mixed signal board is ready. It has 2 AD9833 DDS chips (one for LO, one for IF->baseband), two external AD7478A ADC's, to make it possible to sample I and Q simultaneously, and some of the fun stuff: rotary encoder, two hook switches and a PLED display. And, of course, ATmega162 to rule them all. Well, observe the beauty, check out ADC quality, enjoy. From what I can see now, there is still enough memory and time frame to do decoding of MSF or DCF77 stations in the same uC. So far so good, I'm satisified. And yes, this is all for a Nixie clock project, ha! I really should share the schematics later, that's the best way to make backups.

Every once in a while I have to make my own Eagle libraries for my projects. I've put online what I've got so far. Enjoy!

Just another, check out my one-evening project. It involves floppy drive motor, free energy, air fan and 6 LED's. Everybody is ought to love this!

I published my L6204-based H-bridge control circuit. The document describing it is in Russian only, but the circuit is self-descriptive and universal. There is also printable PCB template free for use by anyone. The page with links is here. L6204 from ST is more effective than previous popular integrated H-bridges because it uses MOSFETS for switching, their switch times are significantly faster. Hence less heat, more efficiency.

Here's a picture of my assembled DAC. Although picture is not a good measure for an audio application, I think it looks cute. And this is a debugger that runs inside of its ATmega8 that allows me to play with CS8416 and AD1955 settings.

Also note that Analog Devices ADM3202 is a significantly cheaper 3.3V replacement for the ever-so-popular MAX232. It is also pin-to-pin compatible.

Here's a PCB of my power supply, this time I got really bored by straight lines and it shows.

Lessons I learned with power supply

1) It seems that a relay rated at 1A must withstand power on currents. But huge bulk capacitors at the input of circuit are effectively a shortcircuit at start. This surges the relay and fries its contacts together. At least a small reed relay can't survive that. Mine has become welded forever. A good solution would be to either use a hexfet power mosfet instead, or just put a NTC thermistor in line with relay to limit the starting current.

2) When programming a microcontroller that requires HV for programming and using its main voltage from one source and +12V from another, never ever let both grounds become disconnected when one of the supplies is on.

After I tested the power supply and soldered down the DAC to the board, I found out that the receiver doesn't work in SPI mode anymore. I haven't figured the root of the problem yet, but here's something I learned by reading its datasheet n'th time. This may not be interesting for everyone, but there are not too many CS8416 projects around and my log here shows among the first hits on google so maybe this will help someone. One very important scoop from the datasheet follows:

CS8416 Datasheet Excerpts regarding hardware/software mode selection

Excerpt one

SDOUT, Pin 26: Serial Audio Output Data (Output) - Audio data serial output pin. This pin must be pulled low to DGND through a 47 kOhm resistor to place the part in Hardware Mode.

Excerpt two

For each mode, every start-up option select pin (except for TX, which has an internal pull-down) MUST have an external pull-up or pull-down resistor as there are no internal pull-up or pull-down resistors for these startup conditions (set after reset).

I hope this is my problem. I missed this part at first. When SDOUT was floating, it could as well be assumed as hi-state and the device worked as I expected it to. When I connected its SDOUT to a finite impedance input, it has likely become effectively pulled down: pull down indicates hardware mode.

This is something I could never expect for a data out line of I2S bus interface, that has no other functions!

3:12AM Update

Yes, it were the pullups that were the problem. I enabled them (had them planted in before, just forgot about the solder jumper on the reverse. I now have a working SPDIF receiver! So happy! I guess I feel like people who assembled their radios in early 1940's. Joy!

Many things have changed since Nov, 29. It's scary how much time has passed since my last post and how little is done yet. It was not all wasted time though. After near completion of board with ADAV801, I figured that the documentation for that chip is very flaky and I can't figure out how exactly it works. Contacted someone with real experience and he confirmed that the documentation is full of errors and omitments and the chip is really overcomplicated, especially for such a simple task as SPDIF receiver.

I thus found CS8416 by Cirrus Logic. It's a straight-on SPDIF receiver with I2S output and SPI/I2C control. It is relatively simple and the documentation is clear, not expensive too. I redesigned teh entire board for it. And I'm very glad that I did, too. Here's the board in flesh.

Currently I have the uC working, USART is up and CS8416 is obeying SPI commands and reporting status. No pics yet, sorry, but there are lots of late corrections on my beautiful PCB - it doesn't look very sexy now.

There are 2 nearest-term goals: make the receiver lock on input signal (as of now VCO voltage is very flaky, even though it senses the signal) and, meanwhile, adopt a bootloader to be able to update the firmware via com-port.

When this is done it would make sense to build the proper power supply before playing with DAC - I use both 3.3 and 5.0 supply voltages, separate regulators for PLL, digital, analog, LCD display and +/- 12V for opamps.

Hi everyone,

it's been a while since my last post. I'm currently off the track with Akipaki, even though shaft encoders are complete. The biggest problem is weakness of motors and it kind of embarrasses me because I can't find better motors. So I put it away for a while until better times (except that the main board is actually very useful for other experimental things - I/O and stuff).

I'm keeping myself busy with a S/PDIF decoder project. As trivial as it sounds, digital audio is not really a piece of cake (not that analog one is, either). At first I tried to build the decoder from scratch. First experiment was just a signal detector and a PLL loop to recover clock from Biphase Mark Coded signal. It was only moderately succesful, because I knew little about PLL's and the nature of incoming signal. Although trashed, it was still a great experiment that gave me good insight into the nature of PLL loops and now I'm not afraid of them. Another bonus was my first successful board with TSSOP16, 0.65mm pitch and an imported bitmap - before I only did 0.8 for TQFP44.

The next step was designing a new board, still in discrete logic, accounting for hard learned knowledge. This design would have proper preamble detection, PLL loop with divide-by-64 feedback, all the decoding circuitry - all there is to output a stream of recovered sound bits. But just as I was contemplating adding 15th package to my circuit, I found out that most decent DAC's require data MSB first. SPDIF data comes LSB first. That would make even more bricks that take real estate. What a bummer.. I quit.

Currently I'm designing a new board, now using integrated A/V processor from Analog Devices, ADAV801. It's a very cute little chip that can do everything one might need to route sounds in all directions, SPDIF in and out, including quality sample rate conversion and two single-ended integrated DAC's (which I'm pessimistic about). Simultaneously I ordered samples for AD1955 dedicated DAC which seems to be far more promising quality-wise, especially if put on a different board. And of course the whole thing is controlled by an ATmega8L, you can't go without a controller these days.

Wish me luck, routing PC audio to another corner of my room turned into a pretty ambitious project. I'll keep you posted.

I completed one of the two shaft encoders for Akipaki. I used some ideas I've found on the web previously, stirred and mixed, and it worked.

Here is a report/tutorial that everyone is welcome to see:

Simple Shaft Encoder for Modified Servos

Hopefully I'll find time and unlaziness to complete the other one soon. Now that I have both boards etched and tech is invented, it must not be too hard to reproduce.

Akipaki certainly can't balance a pole but it can balance itself. So be it, I can't get better motors anyway. Thanks to nice people at AVRFreaks, I could make the tremor mostly go away while rising proportional coefficient to nearly the max.

Next thing to do are shaft encoders, so that I can make Akipaki stop at will and move in a straight line. I want to fit the circuits inside of servo boxes so expect pictures of itsy-bitsy circuit boards soon :)

Pretty slow time otherwise.

2 bettsg: I'm sorry but your site makes little to no sense. No matter how good the information you provide is, I will never see if it requires registration. Requires registration == not free. Compare this to Wikipedia for example, which indeed is free for all.

I made new wheels for Akipaki. This time I used Advanced Security Technologies (see pic):

Isn't it a lovely sight?

I also set RC filter cutoff at 250Hz, increased PID loop frequency to 500Hz and moved the sensor below to make it as close to the pivot axis as possible. I think it helped against the jitter issue.

Ahoy,

I tuned the PID loop. It's far from optimal, I'm sure, but it works. I think it could really help if I tried to refresh control theory and physics (or even, more honestly, finally learn what I was taught many years ago), but how can you read books when you have a screwdriver and an agile mad robot to tweak?

Watch the video. It's about 5 mins long and mostly boring, although it has some funny moments. Yet it's worth a look if you're contemplating a cheap balancing robot.

MPEG, 32Mb WMV, 5Mb

I use the same old chassis, lobo servos, same h-bridge board. The servos are not bad, but I have a suspicion that they don't have enough torque to balance with batteries. As of now, Akipaki is fed 9V by wire (red). The power supply is too weak for 2 motors, probably with batteries they will be even more evil.