Document math generator in signal generator v1.2.0

[jfortune-smith]

Environment:

• OS: [e.g. iOS]
  YES for both laptops: 10.14.6 on one device, 10.15.6 on the second

• SW Version or git tag scopy version 1.1.2 and scopy v1.2.0, respectively

Describe the bug I have a student who gets a completely different screen when she tries to use the MATH functions on the signal generator. She is using a more recent version of scopy, since she just got a new computer and had to re-load the software a day or two ago. I am using version 1.1.2, loaded back in august.

She does not have the option to change the frequency of the math function like I do. I attached my screen shot with annotation of my version number and her screen shots with her version number

Basically she gets a whole different set of controls for the math functions compared to what I see in the older version. We are having trouble reproducing waves in the 1.2.0 version that we were easily able to make with the controls in the version 1.1.2 setup.

Assuming this is a version "upgrade" that simply lacks documentation, does anyone know of any documentation on how to use record length and sample rate (in the newer version) to create math functions the way we would normally write them? I hesitate to update my own scopy this late in the semester since I do not want to lose this particular functionality, since the majority of my students are using the older 1.1.2 version.

Or, is this maybe not a scopy version problem? Could it be something else?

I've attached the .INI file fro my version of scopy, hoping that the function I produced using MATH in my function generator would be transferred to her newer scopy, but that didn't work. I see elsewhere in the scopy related problems that other also see that the math functions are not saved in the .ini files, so this is not surprising.

Thanks for any help or documentation you can send my way.
Archive.zip

[adisuciu]

Yes, the math functionality has been changed in version 1.2.0 in order to correctly represent waveforms from Math equations. You are also correct that there is no documentation :). I'll get to writing it as soon as possible.

The issue that changed this is somewhat documented here and here

https://github.com/analogdevicesinc/scopy/issues/365 https://github.com/analogdevicesinc/scopy/issues/821

It was implemented here: https://github.com/analogdevicesinc/scopy/pull/833/commits/f07220c9901731df04c8f6734e1a0e254e726aae

Basically the previous math generator was unable to generate some interesting waveforms due to the way "t" is implemented. In the old generator, t goes from -PI to PI, which is not accurate. t should be a representation of time, not phase (i think?). In this new version the t variable goes from 0 to record length, with sample rate granularization. This gives you way more flexibility in generating waveforms.

You can either install version 1.1.2 which has the old functionality, or update the equation. I think changing t to "2 pi (frequency of t) * t" , setting the appropriate record length and sample rate should suffice. If you are in doubt you can go maximum sample rate.

All previous releases are on the github page: https://github.com/analogdevicesinc/scopy/releases You can download v1.1.2 here: https://github.com/analogdevicesinc/scopy/releases/tag/v1.1.2

-Adrian

[jfortune-smith]

Thanks!

Joyce Palmer-Fortune Smith College Physics jpfortune@smith.edu

On Nov 20, 2020, at 12:28 PM, Adrian Suciu notifications@github.com wrote:

Yes, the math functionality has been changed in version 1.2.0 in order to correctly represent waveforms from Math equations. You are also correct that there is no documentation :). 'll get to writing it as soon as possible.

The issue that changed this is somewhat documented here and here

365 https://github.com/analogdevicesinc/scopy/issues/365

821 https://github.com/analogdevicesinc/scopy/issues/821

It was implemented here: f07220c https://github.com/analogdevicesinc/scopy/commit/f07220c9901731df04c8f6734e1a0e254e726aae Basically the previous math generator was unable to generate some interesting waveforms due to the way "t" is implemented. In the old generator, t goes from -PI to PI. Which is not accurate. t should be a representation of time, not phase (?). In this new version the t variable goes from 0 to record length, with sample rate granularization. This give you way more flexibility in generating waveforms.

You can either install version 1.1.2 which has the old functionality, or update the equation. I think changing t to 2pi(frequency of t)*t , setting the appropriate record length and sample rate should suffice. If you are in doubt you can go maximum sample rate.

-Adrian

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/analogdevicesinc/scopy/issues/967#issuecomment-731300758, or unsubscribe https://github.com/notifications/unsubscribe-auth/AR2SAFLP4UTSL6J5YRC6LC3SQ2RKNANCNFSM4T5BDDSQ.

[adisuciu]

I added some doc here: https://wiki.analog.com/university/tools/m2k/scopy/siggen?rev=1607446647#generate_waveform_from_math_function

[jfortune-smith]

Thank you!!

Joyce Palmer-Fortune Smith College Physics jpfortune@smith.edu

On Dec 8, 2020, at 11:58 AM, Adrian Suciu notifications@github.com wrote:

Closed #967 https://github.com/analogdevicesinc/scopy/issues/967.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/analogdevicesinc/scopy/issues/967#event-4085771701, or unsubscribe https://github.com/notifications/unsubscribe-auth/AR2SAFNVHPRUQBQJOKW5DFTSTZLMRANCNFSM4T5BDDSQ.

[jfortune-smith]

Hi - I have a follow on question.

Now that my whole class is on the newer version, I need to understand what the record length and sample rate really mean on the math panel in the function generator.
I see in the documentation you gave an example. Why did you chose the values you did for record length and Sample rate?

Sorry if this is a rookie question.

I do understand that the product of record length and sample rate is number of points. AND I can get the same screen you show in the documentation you linked above. In that document you simply state what to use for record length and samples rate. I feel like I know what sample rate is but not record length. (Or, I could be confused about both!)

But I don't understand why a record length of 1ms is better than, say, a record length of 10ms. If I use 1ms as you did, I can't really see the whole wave. If I use 10ms, I can see about 1.5 complete cycles. If I use 50ms, I can see about 12 full cycles, but something funny happens at t=0. I suspect the record length has to do with how the signal will match up at the time when it is repeated. I need to be able to explain to students how to estimate the best values for the record length and Sample rate for whatever function they are using.

Any recommendations or further explanation? Thank you very much - Joyce

[adisuciu]

The signal generator outputs the waveform cyclically. What this means is that when it's finished outputting the last sample, it wraps around and outputs the first sample again, then the second and so on. The speed at which the signal generator switches from one sample to the other is called sample rate (and it's measured in samples per second).

Record length is how much time the waveform will be generated before it wraps around. This value is specified in seconds.

Basically if you define f(t), record length will tell how far will t go (in seconds) while sample rate will decide how often f(t) is "computed". The product of these two values will give the number of samples generated (which has a hard limit of 4MS or 4194304 samples). Having points that are computed more often is (almost?) always better, but in order to have a longer signal(in time) you need more points(which might hit the limit), so there is a tradeoff between signal precision and the period(or record length).

It is up to the user to make sure that the signal will wrap around correctly and the first sample of the waveform will match the last one (or not).

[jfortune-smith]

Thanks - I thought that might be how it worked, but your explanation makes it really clear. Thanks again! Joyce