Extending Quadrature  VCO to negative frequencies

Hi Tom,

I'm replying to your post mainly to keep it alive, as it appears to have been lost in the shuffle. Out of curiosity I tried a simple test -- The circuit below feeds a quad VCO with an input slowly going positive and negative. An oscilloscope set for X-Y mode on the two outputs displays a spot spinning in a circle. The spot changes its rotation from CW to CCW when the VCO input goes negative.

I ran my test on a ADAU1701; does the -1446 behave differently? It seems as if the backwards phase rotation I'm getting implies a negative frequency for a negative input -- as when switching windings on a motor makes it run backwards. Swapping the I and Q outputs for negative inputs produces the same rotation direction for any input, as well as causing a jump in the outputs unless they were equal at that moment. An absolute value block at the VCO input provides the same effect, without the jump.

Best regards,

Bob

Hi Bob,

thanks for answering.

I confirm it works as expected.

I should have done some tests myself, but i was

fooled by SigmaStudio manual where, in VCO description,

is stated:

The input value may be from zero to one (5.23 format), and the VCO linearly interpolates its derived value into an output frequency

It says the value has to be from zero to one.

Many thanks.

Tom

Hello Tom,

Thank you for your appreciation and for marking my answer as correct. The documentation for my C compiler is rather poor, so when contemplating use of an unfamiliar function I often end up writing a short program to test the function before including it in a large project where its behavior would be hard to trace. SigmaStudio is of course also a programming language and compiler. Since its documentation is likewise imperfect, I often try out new cells in little projects like the one above. Any registered user can edit the SigmaStudio toolbox wiki, and more users might be willing to fix documentation bugs it it weren't for its HTML-like script. You know the script is difficult when a "sandbox" is provided for practice edits -- I'm all too familiar with a different sort of sand box. Also it would help if it were integrated with this forum so useful edits would receive points.

Best regards,

Bob

Hello Bob,

what you say is true and i usually do some tests on little projects like you did.

The reason i didn't in this case, is because this was just a curiosity

for the next project, and because i'm struggling with other

bigger problems (i have to complete the job within this week) .

As i see you are really expert, i submit these issues for your consideration.

I noticed that sometimes the "grown" blocks have no contiguous addresses,

in this case i have a simple stereo gain block presenting this problem.

https://ez.analog.com/message/139919#139919

I modified the program and i noticed now the addresses are contiguous,

so my question is : can i expect to have on grown blocks always contiguous addresses

or have i always to treat any block as an individual one? (so reducing host MCU communication efficiency)

Here is the last problem, also reported by another user:

https://ez.analog.com/thread/42294

On 1446 there's a false CRC error indication when there is IIC bus activity; disabling and reenabling

CRC error check fixes the false indication.

I modified the dsp check routine on the host mcu to always try this trick before to reset and reload

the dsps. It works but it seems rather a patch, not a clean solution.

Did you ever encounter these problems before?

Have you any suggestions?

Thanks

Tom

Hello Tom,

I'm afraid I've got no experience at all with the -144x DSPs. Their code setup does appear more complex than that of the -170x -- for example, a microcontroller can boot a -1701 with three simple block writes, without using ADI's label structure. By contrast the -144x needs many writes to boot. Thus where certain elements end up in memory gets more convoluted.

Actually your many interesting posts indicate that you're quite the expert. I enjoy reading them.

Best regards,

Bob