QCW ramp generator

[hammertone]

All,

From time to time, I have been approached with a request to share my QCW ramp generator code.
Everybody should be enabled to build a QCW coil, even though they cannot write code, so here it is:  QCW_ramp_generator.zip

I know that my shot at the code is probably clumsy at best (I imagine some math and code wizzard getting it done in just one line) , but it is functional, so who cares.

Included is a simple schematic, which I include, because I want to emphasize the need for, and beauty of, hardware debounching of the inputs.

So, please enjoy, and go build that QCW

Cheers, Finn Hammer

[shrad]

Hi there

I think you can use binary shift operators in a loop for this, which would be nice

basic use is that it will binary shift a value by a power of 2 : 8 >> 1 = 16, 32 << 2 = 8, etc... so if you do a loop until a treshold value is reached, this is very practical

[hammertone]

Shrad,

Thanks for your suggestion.

As you can probably read in my code, I am at a very basic level. Only recently did I get comfortable with interrupts, direct port manipulation and messing with timer prescale.
The bitwise stuff is over my head, at the moment, unfortunately.

Cheers, Finn Hammer

[shrad]

Thats really simple

imagine an array of 8 bits with a min value of 00000001 and a max value of 10000000 and a logic level of 5V

00000001 is initial value       = V*(1/256) = 0.019V
00000001 >> 1 = 00000010 = V*(1/128) = 0.03V
00000010 >> 1 = 00000100 = V*(1/64) = 0.07V
00000100 >> 1 = 00001000 = V*(1/32) = 0.15V
00001000 >> 1 = 00010000 = V*(1/16) = 0.31V
00010000 >> 1 = 00100000 = V*(1/8) = 0.625V
00100000 >> 1 = 01000000 = V*(1/4) = 1.25V
01000000 >> 1 = 10000000 = V*(1/2) = 2.5V

the rest is thinking of an algorithm which will, in your loop, add shifts to get the steps you want... I'm pretty sure you could find a sketch somewhere that generates a ramp using this technique

you can also use the binary value from 2 to 256 to do some masks (with OR or XOR) on a value to generate another, etc...
from my days of learning microcontroller assembly we played with excel and did some graphs of the values to try different patterns of led flashing, like K2000 and others

[Netzpfuscher]

In a time where a micro controller is so powerful you don't need such "tricks". The ramp of your suggestion lacks a good resolution 8 steps ^^ With a calculation you can generate ramps with higher resolution. If a micro is to slow for a realtime generation of the ramp, I would calculate a lookup table in RAM and play it back in the loop. If the timebase is changed you simply read the LUT slower or faster. If you want, you can save arbitrary waveforms. If you need to save RAM I would make a smaller LUT and interpolate linearly between the points. 

In general, write good readable code and leave the optimization to the compiler. A actual compiler is very smart ^^. If you realy need processing power go to the next bigger micro.


In the UD3 the 64Mhz Cortex-M3 does everything, Ethernet, Synthesizer, Serial, Telemetry and has 80% of CPU unused 

[shrad]

you are absolutely right, but knowing this helps with some notions

however, I would reserve lookup tables to things that require floating point math or real arbitrary like you said

a ramp is even easier with a pwm module which will do everything for you without interfering with CPU after initial setup

nowadays programming is done without taking care of doing things properly just because there is plenty of power and resources are not a problem anymore, so modularity and maintainability are not always the best

the best thing to do is to make functions that are modular, that you can test separately, and define things with clarity in mind

and refactor your code whenever you have a doubt

[hammertone]

Netzpfuscher,

Your viewpoint about compilers and the power of modern micro controllers align with mine, but perhaps It would be a good idea to measure what resolution my code gets me on a 16Mhz  ATMega 328P

AT first I set the ramp to 12.8mS:


After that, I zoom in on a single PWM cycle, which shows good correlation between what is expected and what is being done.
Pulse frequency is 31.25 kHz and pulsewidth is 32mS.
This also reveals that there will be 400 PWM cycles on that ramp : which is fine within the 8 bits expected.




First of course, I zoom into the positive pulseform and set the cursors at the flanks



Now comes the benefit of this fantastic digital scope. ( which was also increadible cheap,  at 400 € ! )

Conveniently, it captures the full waveform, even though I am zoomed in to 5µS/S so with the horizontal position knob, I can roll the signal, and count how many pulses in succession that shares the same pulsewidth:



The number is 5, so the resolution is a paltry 80 steps on this 12.8mS long ramp, resulting in a resolution of between 6 and 7 bits.

Looking at the ramp in well smoothed form:


You can actually count the steps, and considering that:

1) The signal has to be transmitted over inexpensive fiber optic
2) It forms the reference of a Hysteretic buck converter that switches around 10-15 kHz (at the best)

I would say that the code is sufficient.

(But I really would like to see each cycle increment, instead of only each 5th. so I will try to load the code into faster processors).

(( But the really smart thing to do would probably be to take a c++ programming course, and free myself from the constraints of the analogWrite macro ))

Cheers, Finn Hammer

[shrad]

the read and write functions of arduino are well known to be unefficient, a lookup table with a direct binary copy with DMA would be far more efficient, if it is available on your configuration

[hammertone]

Shrad,

The analogue functions , at least, are slow.
The digitalWriteFast and digitalReadFast macros are almost as fast as direct port manipulation, however:

I do not understand how a lookup table can help me to generate a linear ramp, where both length and amplitude are variables read from potentiometers, so I will try another approach, which I found just now:

I will try to calculate dutycycle in an ISP that gets called from an interrupt set by every cycle, perhaps that will give me maximum resolution, eg, every successive pwm pulse will increment, instead of every 5th as now.
There are 476 clock cycles between each pwm cycle, so there should be plenty of time to calculate the ratios.

Cheers, Finn Hammer

[shrad]

a technique I was using is the timer interrupt which ticks when a counter reaches zero (or something like that, I did this 10 years ago)... if you copy the pot value to the counter each time interrupt ticks, you will have an efficient variable delay

during the interrupt routine you also have the time to increment your lookup and configure your PWM value with it which will give you a step

the interrupt delay defines the slope of your ramp and can be any interrupt source you can configure, if the counter doesnt suit your needs

if you want the maximum resolution, it will depend on the PWM module and the interrupt time, but I guess you will be able to reach shorter times if you don't analog read a pot but rather increment or decrement a value by steps with a button push (which can also generate an interrupt to reset the ramp)

for amplitude, I would rather use an opamp at the output

[hammertone]

The 328P will deliver 8 bits resolution at 32kHz, which is more than sufficient.
Loading the code into a Due, it is possible to do 9 bits at 160kHz
The Teensy 4.0, which is another animal, alltogether, is happy to turn out 10 bits at 600kHz, so there really is no need to change the code, there is a rich variety of processors to serve the resolution you want.

Looking for fiber optic transmitters and receivers, I think that the HFBR-1527Z Transmitter HFBR-2526Z Receiver 125 Megabaud Versatile Link hardware, with their sub 10nS rise and fall times are the best suited,

When the teensy is running at 600kHz, the pulsewidth of the wick is around 150nS, so it will be able to transmit all 3 solutions with fidelity.

Cheers, Finn Hammer

[Rafft]

Finn

Huge thanks for the Interrupter + ramp!

here is mine. playing around with the pot/s, I now have a better undersdtanding how QCW should work(mainly on the buck side).
still ironing out what BUCK to use though. Im just aiming for a tabletop version. battery powered (16.8v) to 50v - 100v (for now)

P.S. that is just the filtered PWM output, not the buck 



cheers,
Ralph