TAS3204 ToneGen amplitude is going down

Andreas,

Can you give me the .pfw file you are using that could see this problem, so I can take a look to see whether I could find an explanation/solution.

Regards,

Susan

Susan,

Find attached the requested .pfw

Regards,

Andreas

1033.ProcessFlow1.zip

Andreas,

I could reproduce the issue, let me allocate some time to work on a solution.

Regards,

Susan

Susan,

just let me known if you are still working on this issue an if there might be a solution in view.

In the meantime we have serious problems at our customer side because of this drift we have to reset our devices every day. 

Regards,

Andreas

Andreas,

I am terribly sorry since I really don't have time working on this.  Since this is not a bug, but the nature of the algorithm, I have to find a way to compansate it, but not easy, since TAS3x can't use other ToneGen algorithm like other big chips.

Do you think your customer could use other external source for their tone generation?

Regards,

Susan

Susan,

Thank you for your reply. Unfortunately the circuit board including the DSP is already finished and out to multiple customers.

So we cannot do any layout changes anymore and the use of an external source for tone generation is not possible.

The only way to fix this, is a software update of the DSP.

I understand that this issue is coming from the algorithm itself and will not be so easily to solve.

We will really appreciate your help to fix this problem.

Regards,

Andreas

Andreas

Andreas,

It's still on my todo list and I've been thinking about couple of ideas how to fix it, but when think through, they either would make it unsteable or could have some discontinuity.  So far, I haven't got a solid idea to try yet.  So I really can't promise it's solvable, but I haven't forgotten this issue. 

Maybe we could work out something in between, if they could live with some compromised solution, for example, automatical reset the ToneGen by itself after sometime, would that work? it would definately create some discontinuity, but if there's something they could accept, we might be able to do that.

Regards,

Susan

Susan,

As a workaround we do at the moment a reset of the whole DSP. If we are connected to a server process via TCP/IP we can do this at a time, when the device is not used. But if the system works stand-alone the reset will be done e.g. every 24h. Because we do not have a real time clock this depends on the startup time of the device. In that case the reset of the whole DSP may come at a time when it is not acceptable.

Your suggestion “automatical reset the ToneGen by itself after sometime” will be absolutely fine for us. Your mentioned discontinuity will be no problem for us.

So if it is possible to restart/reinitialise only the tone generator and not the whole DSP via I2C it will absolutely OK for us. But as far as I can see this is not possible at the moment via I2C but maybe you have an idea to do this.

Regards,

Andreas     

Andreas,

I need to modify the ToneGen component and give you a new one, you could also do it yourself,  a lot of our customers make changes based on their needs.  It would be easier for me if you could send me a flag via I2C, so whenever I receive the flag, then I reset the ToneGen to it's initial condition, and then clear the flag. 

Do you think this is something acceptable at your side? 

Regards,

Susan

Susan,

Thank you for the reply. Yes, it will be fine for us to use a modified ToneGen from you, which can be resetted from outside.
By using a flag to reset the ToneGen please tell me what I have to send exactly via I2C in that case.

Regards,

Andreas

Andreas,

It would be a runtime parameter that I will get from you over the I2C, I don't know yet what I want you to send, but I think just a non-zero number should be fine.  I will try to find sometime to make a component and give it to you.  By then, I will know exactly what you need to send.

Regards,

Susan

Andreas,

I just found out that the .dll used by ToneGen component is not the standard .dll for process control controller, so I won't be able to add another runtime property without touching the .dll.  It would be too time consuming to recompile the .dll since it's part of the PPS big environment.

We have another Flexitone generator which is using the standard process control controller .dll which I would be able to add another runtime property.  Do you think you could use the Flexi tone Gen instead?

If you could switch, then I could modify the Flexi Tonegen for this purpose.

Regards,

Susan

Susan,

Maybe the FlexiTonGen could be an alternative.  
But we need a 19kHz sinus at the output. As far as I can see the frequency in Purepath can only be set in steps. The nearest step is 0.008333 which is the equivalent to 20kHz when using a sampling frequency of 48kHz. At default 19kHz is not supported. Maybe there is a way to change this?
When using the normal ToneGen we set the amplitude to  8000.0 in our application.
When using the FlexiTonGen there is no amplitude but a gain that can be set. Can this gain also be set so that we get an amplitude equivalent to 8000.0?  
So if it is possible to get a sinus exactly 19kHz and the amplitude is also in the same range as used by the normal ToneGen it will be fine for us to switch to the FlexiTonGen.

Regards,

Andreas  

Andreas,

Yes, the frequency can be done, I can make that configurable, you just need some calculation yourself, since TAS3x doesn't have the power to calculate that.  As for the amplitude, it's just a scaling, I think that shouldn't be a problem.

I'll start to work on it, it may take some time since I don't have much allocated to TAS.

Regards,

Susan

Susan,

OK. So we'll wait hearing from you again.

Thank you.

Regards,

Andreas

Andreas,

I created a new component based on the Flexitone component, but it's not thoroughly tested yet.  Here is how it should work: I put in an alpha and beta and a reset flag at the run-time configurable parameter list.  You could compute the alpha and beta value based on the fs and f0 where fs is the sampling rate and f0 is the target frequency, I've put the formula there with the component at the note section for the parameter.  Please note the 2^16 offset for Beta.  Gain=1 equals to 65535 in the ToneGen component, so you could calculate the gain based on what value you want.

I have only 2 values for reset_flag, when you want to reset the Tone Gen, you set 1 to reset_flag, I'll clear the flag after the reset, so it's not easy for me to check whether it's working or not until a day later, so I think it's a good idea that you could test it at the same time.

So, I'll attach the component here and please let me know what you find out.

Regards,

Susan

Susan,

Many thanks for sending us the new TonGen. Last week I was on vacation, so I installed and tested it today.

I made the calculation of alpha, beta and gain parameters according your advice and our needs.

It runs now on our demoboard and time will show if it works or not.

Regards,

Andreas

Susan,

I have now finished some long term tests. 

For this I used a small PurePath project with only two components. One component is the old “Tone Generator” and the other one is your new “ToneGenerator_Reset” based on the FlexiToneGenerator.
Both are going directly to the DAC_Out.

I measured now over one month the actual amplitudes of both tone generators.

Here are the measured values:

Old tone generator: Start: Vpp=556mV  After one month: Vpp=256mV

New tone generator “ToneGenerator_Reset” without using reset functionality: Start Vpp=568mV   After one month Vpp=536mV

As we can see the old tone generator amplitude is going down by nearly 50 percent. With the new one the drift is only about 5 percent.

We now use the new “ToneGenerator_Reset” in our application. Even so the drift is not so much, we make a daily reset of the tone generator via I2C and drift is no longer an issue for us.

Once again many thanks for your competent help.

Regards,

Andreas

Andreas,

Thanks for telling us the good news, I am very glad that the issue is resolved.

Regards,

Susan