Older blog entries for svo (starting at number 13)

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.

Today I was very very much impressed. I asked a question in FreeRTOS support forum on sf and got a positive response in less than 5 minutes. I guess this is a coincidence, but what a great one!

I rewrote a tiny part of FreeRTOS guts to accomodate it to Timer0 instead of its original Timer1.

Timer1 is now fully at my disposal.

Just a few hours of decoding the riddles Atmel documentation team had created for me, and Timer1 is streaming 2 pretty PWM pulses that are proportional to inclination!

Let's measure the efficiency: evenings since first boot - about 5. Functionality achieved: everything I had on the PIC board plus more.

Sure, the code is not as tight as it is when you code in assembly, but who really cares? The thing runs more smooth than ever, the code maintainability is times-fold better.

w00t! what a day, a perfectly wasted Saturday :)

Results:

:) FreeRTOS is up and running on my mega32;

:) TWI/I2C is working and display is interfaced through RTOS queue;

:) PID term coefficients are read upon startup and displayed;

:) Error term (inclination) is being measured and displayed continuously;

:) Other tasks run beeping and flashing asynchronously, inducing happiness around;

:( FreeRTOS AVR port uses 16-bit Timer1, exactly the one I was planning to use for phase-correct PWM generation. What a bummer! Hopefully it doesn't really need the 16-bitness of that timer, maybe I can hack it to use the other one;

Aside from that last little trouble which I'm sure can be solved, I don't have words to express how happy and easy it is with a sane uC, C-compiler, decent simulator too (talking about WinAVR/gcc and AVR studio, remembering MPLAB IDE, shuddering) - it's just so smooth and pretty now.

Of course I guess it would not be as smooth if I just started off for the first time ever. After all PIC made me learn a lot of stuff and I'm grateful.

Moo!

My ATmega32-based board is working. So far I only have the uC, the led and the beeper. The new design also has the reset button and three potentiometers for PID term coefficients input. I'll need some time to figure how to do more sophisticated stuff than just blinking the led and beeping. Happy happy day.

Here's a pic of the new logic board (top) and the ISP programmer I quickly assembled to program the AVR (bottom). The schematics is based on PonyProg-STK200, but altered a little to accomodate what I had handy (namely, 74hc245 instead of the 244).

The experience with programmer software is not as smooth as I expected. The so-much praised PonyProg is a little bit TOO universal and it was not easy to figure what was going on. It works now though.

avrdude from WinAVR distro was a little more friendly at first (not user-interface kind of friendship though), but failed to read the fuse bit words.

Also a note on PCB's. I kind of found the proper combination of exposure time/distance for paper prints, finally. With my uberlamp (it's some hardcore UV lamp, not the regular kind that looks like a daylight lamp), it takes not less than 60 minutes from 30cm distance through an oiled print on regular office paper. I'm afraid this won't work with more commercially available lamps - just to give the idea of the power of this lamp - shining for 10 min from 10cm distance makes oil burn to the surface of photoresist and enough UV gets through the dark areas of the template to render the entire exposure useless.

Hello,

what I write here begs to be a forum post, except that I can't find a forum to post into - so I have some questions:

1) Is there a way to contact other people on robots.net other than by posting in the diary?

2) Is there a robots.net forum somewhere? If it exists, I can't find any links to one in obvious places here.

to Pedro14: unfortunately for your project, I2C bus is not, and can not be, wireless. I2C was conceived at Philips as a mean to make many chips in a single device talk to each other via just 2 wires. You will probably have to deal with it when interfacing to memory chips, some sensors and displays. For example, I use it to send data to the display of Akipaki. Sometimes it is also called TWI (Two-Wire Interface), sometimes IIC, maybe there are some other names. Idiosynchratic of I2C are open-drain terminals, addressable devices and strictly octet-oriented communication protocol.

I think that your project is very complicated by itself, even without wireless communication. It is probably a good idea to develop the basic functionality first, probably develop a simulation of the entire system on a PC - that alone would take a lot of time. And maybe when the proof of concept is ready there will be some pretty, readily available, single-chip radio interfaces as simple as I2C is in the world of wires.

4 older entries...

X
Share this page