I see a bug in the mover waveform: the waveform sometimes doesn't respect the value of duration if it is higher than ~50 ms. If I change the duration to 100 ms, the right (+x) button takes steps of correct duration, but the left (-x) takes quicker steps. Same behavior on y and z buttons.
I am using GXSM 3.47.1, koala waveform. I just noticed this issue because my amplifier is low current so I need a slower waveform to that amplifier to drive it.
Has this been fixed in more recent versions?
Thanks,
Craig
Last edit: Craig Howald 2019-01-26
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Percy did change the mover code on 31.12.2018, but this should not affect (or fix) this bug - at least, I do not see anything obviously changed after my last code comitment.
I will have to test it again. Can you check, when your version was compiled in the help menu? is this a version from the launchpad repository/live-DVD or a self compiled one?
Just a note: There is an upper limit for the duration of the "wave-form" due to memory restrictions and the 75kHz sampling frequency...
Thorsten :-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
What is the limit on duration? I have managed to use 50 second long waveforms for testing purpose (but they are 50 ms for -x). I need 1 second long waveforms for my application.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
But the DSP (MK3) can slow down by 2^31 x based on 150kHz max sampling rate for outputting wave samples.
Then this combined with your actual wave_length (sample/period) gives the actual possible period.
The MK2 is limited to a slow down by 2^15 x.
Last edit: Percy Zahl 2019-01-25
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Interesting, have to check on this. Any scope screenshot? -- PS: Slipped into some little more involved DSP core hacking via new requirements... in a way builing a completely new and own micro RT DSP kernel.... and moving away from a mololytic one shot data processing interrupt. Some likely hardly noticable but present issues are been addresses and a performance boost likley to happen soon!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The bug is also reproduced with gxsm3-3.49.1 - which needed also an update of the dsp firmware.
More strangly: If duration is below or equal 54,606 ms everything is okay, above the two buttons have different frequencies. This is almost have of the maximum default duration of 110 ms....
Thorsten :-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Check on waveform generation but looks okay. For the value above stated the MOV_wave_speed_fac changes from 2 to 3. Misinterpretation on the DSP? ... But just found one reference in FB_spm_autoapproach to wave_speed ...
Thorsten :-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Q: do you run the PAC-PLL processing? -- I am asking as of new developments and insights actual real time timings and limitaion (of the "old" DSP code architecture)...
Is it 100% consistent?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
"Is it 100% consistent?" This question is hard for me to decipher. What do you mean by "it"? The incorrect timing is consistent: something is setting the maximum duration at about 50 ms (I believe the 54.606 ms that Thorsten quoted) for the left button, but not for the right button, which does allow generation of the waveform I want.
Last edit: Craig Howald 2019-01-28
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ok if that is the case and one direction works this is a high level issue with the waveform generation and timing setup. The DSP has no knowledge about directions and only plays the wave form as provided.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Any +/-X... assymettry is certainly a bug in teh wave form creation algorithm.
OK, it's a while, I checked on the limits again:
1) the DSP code is pretty much not limiting anything right now. And provides a speed-factor to "slow down" the output rate by N=1 (default) ... 2^31 what woould crawling slow.
2) In GXSM the wave form length for all used channels!!! togther is set to:
MOV_MAXWAVELEN 4096
GXSM currently determines this speed facor to make optimale use of the MOV_MAXWAVELEN.
This means: for 2 a channel output 2^31* 2048/150 000 = max seconds per wave form including the a spacing of wave forms -- the actual periode. Huge....
4) I identifed a missing final double check of actual max length send to the DSP -- what can cause (random noise or data from uninialized DSP memory read) -- but only if the wave form creation at the end computed a max_wave_length is exeeding MOV_MAXWAVELEN. What would mean a bug in the wave form comutation algorithm.
In my current code I added this extra sanity limitiation at the very end of create wave form.
if (mover_param.MOV_wave_len >= MOV_MAXWAVELEN)
mover_param.MOV_wave_len = MOV_MAXWAVELEN-1;
-P
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I see a bug in the mover waveform: the waveform sometimes doesn't respect the value of duration if it is higher than ~50 ms. If I change the duration to 100 ms, the right (+x) button takes steps of correct duration, but the left (-x) takes quicker steps. Same behavior on y and z buttons.
I am using GXSM 3.47.1, koala waveform. I just noticed this issue because my amplifier is low current so I need a slower waveform to that amplifier to drive it.
Has this been fixed in more recent versions?
Thanks,
Craig
Last edit: Craig Howald 2019-01-26
Hi Craig.
Percy did change the mover code on 31.12.2018, but this should not affect (or fix) this bug - at least, I do not see anything obviously changed after my last code comitment.
I will have to test it again. Can you check, when your version was compiled in the help menu? is this a version from the launchpad repository/live-DVD or a self compiled one?
Just a note: There is an upper limit for the duration of the "wave-form" due to memory restrictions and the 75kHz sampling frequency...
Thorsten :-)
I am running from the launch pad.
What is the limit on duration? I have managed to use 50 second long waveforms for testing purpose (but they are 50 ms for -x). I need 1 second long waveforms for my application.
It's not designed for super slow wave forms.
But the DSP (MK3) can slow down by 2^31 x based on 150kHz max sampling rate for outputting wave samples.
Then this combined with your actual wave_length (sample/period) gives the actual possible period.
The MK2 is limited to a slow down by 2^15 x.
Last edit: Percy Zahl 2019-01-25
Interesting, have to check on this. Any scope screenshot? -- PS: Slipped into some little more involved DSP core hacking via new requirements... in a way builing a completely new and own micro RT DSP kernel.... and moving away from a mololytic one shot data processing interrupt. Some likely hardly noticable but present issues are been addresses and a performance boost likley to happen soon!
Okay, I can confirm different frequencies for up and down steps with the Koala waveform on gxsm3-3.48.0. I will try the latest version ...
There is also a glitch in the sine, but frequency is okay.
I will check details (and a newer version 3.49.x)
Thorsten :-)
The bug is also reproduced with gxsm3-3.49.1 - which needed also an update of the dsp firmware.
More strangly: If duration is below or equal 54,606 ms everything is okay, above the two buttons have different frequencies. This is almost have of the maximum default duration of 110 ms....
Thorsten :-)
Check on waveform generation but looks okay. For the value above stated the MOV_wave_speed_fac changes from 2 to 3. Misinterpretation on the DSP? ... But just found one reference in FB_spm_autoapproach to wave_speed ...
Thorsten :-)
Mark 2 or 3 DSP?
I am seeing this issue on MK3-PLL.
Q: do you run the PAC-PLL processing? -- I am asking as of new developments and insights actual real time timings and limitaion (of the "old" DSP code architecture)...
Is it 100% consistent?
Yes, I sometimes use PAC-PLL processing.
"Is it 100% consistent?" This question is hard for me to decipher. What do you mean by "it"? The incorrect timing is consistent: something is setting the maximum duration at about 50 ms (I believe the 54.606 ms that Thorsten quoted) for the left button, but not for the right button, which does allow generation of the waveform I want.
Last edit: Craig Howald 2019-01-28
Ok if that is the case and one direction works this is a high level issue with the waveform generation and timing setup. The DSP has no knowledge about directions and only plays the wave form as provided.
Any +/-X... assymettry is certainly a bug in teh wave form creation algorithm.
OK, it's a while, I checked on the limits again:
1) the DSP code is pretty much not limiting anything right now. And provides a speed-factor to "slow down" the output rate by N=1 (default) ... 2^31 what woould crawling slow.
2) In GXSM the wave form length for all used channels!!! togther is set to:
MOV_MAXWAVELEN 4096
GXSM currently determines this speed facor to make optimale use of the MOV_MAXWAVELEN.
This means: for 2 a channel output 2^31* 2048/150 000 = max seconds per wave form including the a spacing of wave forms -- the actual periode. Huge....
4) I identifed a missing final double check of actual max length send to the DSP -- what can cause (random noise or data from uninialized DSP memory read) -- but only if the wave form creation at the end computed a max_wave_length is exeeding MOV_MAXWAVELEN. What would mean a bug in the wave form comutation algorithm.
In my current code I added this extra sanity limitiation at the very end of create wave form.
if (mover_param.MOV_wave_len >= MOV_MAXWAVELEN) mover_param.MOV_wave_len = MOV_MAXWAVELEN-1;-P