Bit Angle Modulation (BAM) in a PIC

[lanyong]

how to do it?

pls post the code.

bam is possible, we can change the H or L in two clocks in pic18. so 10M/(2^13)/2=1220.703125/2=610.3515625

i have 8 group i/o and get the 2450.98Hz 8 bit bam equl to 1 i/o:2450.98*8/(2^13/2^8)=610Hz.

the min time is 0.2us to change the i/o's voltage

[sanch0]

I have working code for 14bit 610hz BAM with 16 output PWM channels (code could be updated to get more channels with external logic if needed), but i didn't tried to resolve flicker problem with BAM yet. I think that simple signal mirroring doesn't help to fully avoid flicker(s), it just makes it significantly lower, but maybe also affects visual perception of signal "decreasing" actual refresh rate. And there are other ways to avoid flicker trouble, too. However, MIBAM is very good approach, thanx to it's simplicity in combination with reasonable effectivity. Thank You, Darrel Taylor & RadikalQ3 for giving good explanations and usefull thoughts. Btw, additional advantage of MIBAM method is that it might slightly reduce level of generated EMI.

[Darrel Taylor]

It's amazing how many people have come here to tell me that the Mirror Image won't fix BAM's blinking problem.

With the mirror image, there is absolutely NO blinking AT ALL. (Not even with a video camera).

Of course everyone admits that they've never even tried it.
But yet they still feel it's ok to tell the world that it won't work.

All I can do is return the favor ...
16 channel, 14-bit BAM, at 610hz, with a PIC, is IMPOSSIBLE.

It was bad enough when you said 13-bit. But now with 14-bits, the minimum period would be 0.1 µS. There's NO WAY you can set 16 outputs to the desired states with only one instruction, then set them all to new states on the very next instruction.

But then ... "I've never tried it".
<br>

[Ioannis]

And Christ did not ask for anything. He was crucified though...

Ioannis

[sanch0]

It's amazing how many people have come here to tell me that the Mirror Image won't fix BAM's blinking problem.

With the mirror image, there is absolutely NO blinking AT ALL. (Not even with a video camera).

Of course everyone admits that they've never even tried it.
But yet they still feel it's ok to tell the world that it won't work.

All I can do is return the favor ...
16 channel, 14-bit BAM, at 610hz, with a PIC, is IMPOSSIBLE.

It was bad enough when you said 13-bit. But now with 14-bits, the minimum period would be 0.1 µS. There's NO WAY you can set 16 outputs to the desired states with only one instruction, then set them all to new states on the very next instruction.

But then ... "I've never tried it".
<br>

Sorry for my poor english, maybe u hadn't understood me as it was supposed. I don't want to flame here... i feel a bit tired myself and i'm way too lazy now to start explanation again. I had thought to upload code here, but now i'm not sure of your reaction. Maybe even then u gonna blame me). Just read my previous posts again. But i don't want to disappoint u and u a free to think that i'm lousy liar))) Actually i started to code in ASM 17 years ago. And i don't have to prove nothing here. Yes, it works. Yes i didn't tried MIBAM yet with _MY_ 14 bit _BAM_ code (which was written about half year ago). I work periodically for local advertising companies and earn some $$$ from things i develop using my older 13 bit code for 18F, which actually isn't BAM nor "clear" PWM. (which, btw could also be upgraded to 14 bit 610Hz, but don't ask me how, as i had already described it). Sorry, do not have enough strength to continue that, i feel myself wasted a bit 8] best regards....

[sanch0]

example... sorry it's static...

[Darrel Taylor]

... Yes i didn't tried MIBAM yet with _MY_ 14 bit _BAM_ code (which was written about half year ago). ...

I'm sorry you're so tired, and I wouldn't want you to waist any more of your time.
I'm sure trying to explain something that's IMPOSSIBLE would really take a lot out of you.

But if it makes it any easier for you ... I don't need to see your whole code, or have a big explanation with pictures and billboards.

But I would like to know how you got past this one single problem.

... with 14-bits (BAM @ 610Hz), the minimum period would be 0.1 µS. There's NO WAY (a PIC) can set 16 outputs to the desired states with only one instruction, then set them all to new states on the very next instruction.

Since you do ASM, it's only 2 lines of code.

I would be apologizing profusely for weeks to come if you could.
<br>

[sanch0]

What exactly do you mean saying "single problem"? u have just described 2 problems) IMHO. of course u can't operate 2 ports at the same time, but u can make somekind of "interleaving" and operate them separately. Here comes out one problem we had spoke about it above - blanking interval. If only 16 channels (actually even more) needed, this could be solved in two ways - design more complex code avoid it (but it's very hard and non-effective combined with time-excessive code for maximum refresh rates and resolutions (more than 8 bits of output per channel); u can just increase LED current accordingly or u can just forget it, as human eyes (actully because of brain's perception algo, which integrates all incoming signals))) do not see much difference between duty cycles of 100% and 90%, or even less.
More serious problem is to make 1Tcy output discretization. But i described this trick before - this could be done using state prediction in code - u can _change_ (set or clear 8 bit of file register and set, reset or toggle single bits) for example using CLRF [filereg] command (or SETF, ANDWF, IORWF, ADDWF and all other byte-oriented commands) in proper place of execution stream. Of course u can't copy value from other location or modify port value in single 1Tcy instruction). It works, i didn't lie.

I didn't sayd that MIBAM doesn't work!!!

i said:
"I think that simple signal mirroring doesn't help to fully avoid flicker(s), it just makes it significantly lower, but maybe also affects visual perception of signal "decreasing" actual refresh rate."
as u can see, i didn't said that i'm sure MIBAM doesn't work (?), it was "suggestion", of course.

[btw, how can u measure flicker power or detect flicker existance when it appear at lower bit transition. This "flicker" effect depends on individul perception's sensetivity and many "watching" conditions. There is such science called psychophysiology, if i'm right).]
I still suppose that MIBAM DO have some minor disadvantages!

First - lower "refresh rate" (it's very important for most of my designs, as i like to get _PERFECT_ fadings, color slides or animations, as i'm very expirienced in this stuff, believe me. Most people accept much lower visual quality and even do not see any differences at all, where i see it) Maybe it could be also avoided forcing some blanking between two MIBAM parts? it should help...

Second - - floating period phase and frequency of signal. it's advantage too, as it decreases EMI amount generating in wider spectrum range without spikes on certain frequencies))). actually it's not realy important for most simple projects. situation changes when u work with huge led amounts, huge currents, long wires, when u must take into account effects of parasitic capasitances, inductivities, switching delays with specific LED drivers etc.

It's important to me to find compromises between time/memory-excessive code, it's complexity, resolution and speed, as i want to use LP INTs to
communicate at higher bitrates. Unfortunately, low-end PIC MCUs do not have larger FIFO buffers. With my present 13/610 PWM code only about 150 kbps speed could be achieved. And code itself uses significantly more RAM than my "flickering" 14/610 BAM, so i search for best suitable desicion for my designs and my aesthetic requirements (visual influence))).

Btw, if u didn't noticed, I thanked You for good work. And now I especially thank RadicalQ3, as his post helped me to select directions of my "engine" development. Somewhen later (got much other things to do, too) i could share some of my achievements with you, if you interested. But i'm not interested in disputes too much)))