We're back..

I've been busy (very), but I'm still here...
Starting the first post of the year on the end of March is not the best indication of a success blog (which I don't have)... but I'll try to post some old stuff that I did meanwhile.
I've lost a bit of touch with the Arduino and last time I check things have gone mainstream and big (check this one out, an ARM Arduino). I have an old project done two years ago to post.
Meanwhile I've started with the RaspberryPi and how to connect it to some hardware. Although I don't really like Python (the strict indenting drives me mad), you can also use C to program it.
Well all the people of posted questions I've published them, for those with questions just shoot.


AVRStudio 6.1 and Code Composer Studio 5.4

A new second hand laptop and a new windows XP re-install and all the tools for micro-controller development... If you are looking for a comparison between the above tools stop reading. **** This is a public bashing of both tools, they are s##t ****
I recently bought some MSP430 development tools from Texas Instruments (ez430 chronos) and went on to install the "Offical and supported Development tool" Code Composer Studio 5.4...

It has the following problems:
- very large program, based on Eclipse (that also suffers from some of the Emacs problems of growing ad nausea in features that only a few people use).
- incredible tools for managing projects from the IDE, fantastic.. except this is a micro-controller development platform. If you program has more that 32 code files (.c or .asm) you probably should rethink you program... and if RCS or CVS cannot manage your multiple projects... you should not be developing for micro-controllers.
- After many tries (I am not very patient, nor skillful with point and click interfaces) I managed to compile my program and debug...
- the main window has so many subwindows that it is impossible to use on a laptop, you need a 32 inch TV to use the interface... it is nuts!

I thought that was horrible, but then I installed AVR Studio 6.1, if the former program (CCS 5.4) is large the latter is huge...

Has the following problems:
- during install, further "support modules" are downloaded, including one of 1.2Gb!!! Microsoft Visual Studio something - HORRIBLE!
- combining AVR and ARM tools is a bad idea, why do I have two toolchains when I only want one of them!
- same problem with the windows as CCS but in some way we have less subwindows.. maybe its a bit better..
- to update you need to register! why ? did't I already had to register to download... leave me alone! And then it fails with a crash! 
- I tried to install AVR Studio 5.1 first... but doesn't work, fails during install....
- I'm going to try to install 4.19... I need to update my AVR Dragon and AVR ISP2... that's why!

Ahhhhhhh! were did all go so wrong! Give us an editor, a simple project manager, an assembler, a c-compiler,  a simulator and a debugger, that's it how difficult can it be! give us some icons in the interface and nothing else!

Uninstall both horrible tools, install AVRSTudio 4.19 (because I need the simulator a bit), avrsimul in linux is getting better so maybe in the future there will be no need even for this.
Developing with MSP430 appears simple in linux (although the install is a bit more complicated), the tools for AVR install quite easily with a special one-click install for OpenSUSE (installing arduino tools).


HF on the ATtiny15

I wanted my class E amplifier to be driven by an Attiny15. The idea is to build a HF (6.78MHz) low voltage and low power beacon.
The maximum PWM frequency attainable using the factory OSCCAL value, and using OCR1B=2 and OCR1A=1 is 8.525MHz with the only possible duty cycle is 33%. With OCR1B=3 we get 6.393MHz, OCR1B=4 we get 5.115MHz.

I want to use my beacons in the ISM band of 6.78MHz so the second value (OCR1B=3) is the closest. I managed to output a duty cycle of 25% (OCR1A=1) or 50% (OCR1A=2), this is perfect for a class E drive as 50% is available. The final tuning was done with trial and error on the OSCCAL value until I got the correct frequency.
In my tests, the factory value for OSCCAL (of all the Atmel Tiny15L I tested) would get you within 1% of the nominal frequency 1.6MHz, but with frequency measurement and tuning I got to within 0.5%.

Did a couple of other idiot measures and observations.
- The program memory of the ATtiny loops, the PC is only 9bits and when the last instruction of Program memory is reached execution continues for 0000.
- A NOP consumes less current that an rjmp +0, not significantly but noticeable. I fill the memory with each instruction and measure the current with or without BOD. The second instruction also take double the time of execution.

RJMP+0,BOD - 3537uA (AVG)
RJMP+0,NO BOD - 3494uA
NOP,BOD - 3503uA
NOP, NO BOD - 3458uA

- OSCCAL after reset is cleared and the measured clock frequency is 1.1MHz, when taken to 0xFF the frequency is 2.083MHz.
- Clock jitter of the oscillator. I filled the program memory with the following:
sbi portb,portb1
cbi portb,portb1
rjmp lp0000

I would then trigger the scope at the low level at the end of the loop. This gap would last longer than normal, then it is easy to trigger on it. You can just see it under the trigger arrow in the picture above.

I would the trigger to the flank increase persistence to max and let measure. the jitter.

The waveform goes up quite fast (in less than 10ns) with the oscilloscope probe as load. With a gate of MOSFET... it's not so good...


Class E - selecting a switch

After the initial results (with a simulated ideal switch) here, had to design a real circuit. Having seen a lot of projects with the 2N7000 and having a few in my surplus bin, I used it in the simulation.
Finding spice models for the 2N7000 is easy, being the only problem that there are so many. I used the typical Coss of 2N7000 (11pf) and subtracted from C1 in the Sokal 2001 formulas.
In order to stop working at the PC for so long, I started using the calculator more often to find optimum parameters and just do a short simulation at the PC. Here's the print out from the calculator.

QL is the Qload of the circuit, K1 is the ratio of XL1 to XC1 (unadjusted) (mentioned in Sokal 2001), one could do some iterative calculations but a simple adjustment seems good enough.
Simulations, unfortunately are not handled (yet) by my HP42S... so here's the ngspice output.
Spice output using 2N7000 Vgs=5V

There was something wrong! After having a closer look at the datasheet of the 2N7000, the drive voltage was clearly a problem. My system is 5V only (Vcc and Vdrive) and it is clearly insufficient to fully drive the 2N7000. Once the drive was changed to 12V the waveforms looked much better.
2N7000 with VGS=12V

Since the system will be 5V only I had to find a logic level drive MOSFET, the ones I had available were IRLD024 or IRLR024N. Unfortunately there are no spice model available for the IRLD024 (Vishay or IR), so I will use the second one (IRLR024N) for simulation and the first one for the final circuit.
Class E with IRLR024N
This last waveform starts showing some signs of out of tune (VDS is 5V at turn-on) but the Sokal documents give hints on how to tune.