What i wanted to know is if SYS1.6 is the same as SYS25116.
Thank you!
What i wanted to know is if SYS1.6 is the same as SYS25116.
Thank you!
SYS1.6 and SYS25116 are the same.
This versione derive from the original SYS1.50 modified, the version 1.6 is the the sixth release, the correct name was SYS15116 but when i have renamed it, i’m wrong!!
I’m sorry!
SYS1.6 gives me a lot of errors when compiling with IAR. Missing libraries, errors in the code and can not generate HEX file.
I have not ever worked with this compiler.
pmos69 or some other, can I send changed files, and you can compile a new SYS25116.
Thank you.
Anybody compiled this SIS file and publish it.
There’s a long time no one posts in this forum. SYS 1.61 site (pmos69 . net) has lost its domain, how can I get it now?
Yes, those links don’t seem to work now. They were working fairly recently.
I think you can also get the files from here
<LINK_TEXT text=“https://github.com/gabonator/DS203/tree … ns/pmos129”>https://github.com/gabonator/DS203/tree/master/Resources/Applications/pmos129</LINK_TEXT>
Is it just me or does the display not refresh properly when using 200uS/div. or 500uS/div. horizontal sweep? The very left-most column of pixels in the waveform display jumps all over the place with the input signal, but the rest of the waveform does not update as well. If I set “TrOFF” and give up triggering it seems to update fine. Is this a problem with the way triggering is performed? No combination of trigger settings alleviate the issue other than disabling it in those timescales.
Has anyone else experienced this issue? Is there a work-around?
I don’t have a problem with refresh / trigger on those timebases (or any others).
So if you just do a loopback from the internal sig-gen to channel A on Auto trig 1/2 level then you don’t get a refreshing display which changes with sig-gen frequency and waveform?
What versions firmware are you running?
I am on HW 2.7 with SYS 1.50 v1.6 and GCC APP v1.29. I have not flashed my FPGA as it came stock with 2.61 (All the HW 2.7s do).
You are absolutely right in your description of the problem. Though that is not the only time I get refresh issues, it is certainly the most pronounced. 200uS time-base is completely unusable for me. This is not the case with the stock SYS/APP or with the stock SYS and Gabonator’s APP.
Those are the versions I use (but with HW2.6) and I don’t see a refresh problem. Maybe try downloading the firmware again and if the problem is still there post it here so it can be double checked for content. Other than that I think it needs the dev to comment.
Help!
Sorry for my english ))
I bought DS203, but sluayno replaced
Sys file V2.72 on V2.61. Everything works,
but is worse. Offensively. How to return me the new version? I couldn’t find in WEB.
Help, please! Thanks!
I am struggling to understand your post here. See if you can answer these questions.
- You have just got a new DSO203. Yes / No
- It was working OK with the supplied firmware. Yes / No
- You have changed some of the firmware and it is now not working properly or you don’t like it. Yes / No.
(Please give any details of what is not right)
- What were the names of the files you used when changing the firmware?
(I don’t recognise the number 2.72)
- You wan’t to revert to the original software. Yes / No.
- Have you read the Wiki on upgrading firmware which also has links to the standard stock firmware?
<LINK_TEXT text=“http://www.seeedstudio.com/wiki/DSO_Qua … g_Firmware”>http://www.seeedstudio.com/wiki/DSO_Quad:Upgrading_Firmware</LINK_TEXT>
Hello,
i have a problem with my DSO203 Quad.
The Firmware is:
FPGA 2.61
SYS25116
APP V1.29 (APP G251)
The trigger-function is disrupted under the following conditions:
- AUTO Timebase 200us
- Measurement Screen off (14 div Scope Screen)
An event occurs only when activity of a knob. (The beam is frozen) It ist the Measurement Screen on, than works the trigger normaly. In all other timebase settings (1ms, 5ms, 500us,…) works the trigger correct.
Do you have any idea about this?
Thanks
I am running same code and tried to reproduce this just by looping back internal sig generator.
Set to 200uSec auto trig 1/2 level full screen with circle button press. Triggers OK and screen updates properly when I change sig gen waveform, level and frequency.
This does sound weird to be a problem just on one specific setting. Someone a few posts back was saying something similar.
Maybe there was some bad images around at some point. Have you tried reloading the app and sys file?
Failing that you could post up the zips you are using for us to check out.
OK I have reproduced this problem now.Looking over the posts it hinted that the display was frozen until a button on the Quad was pressed.
By doing a quick test with the internal signal generator of course you don’t really see this as you have to push a button to get the signal generator to do something different and that itself triggers a refresh.
By using an external signal I do see that on the 200uSec range full screen there is a problem. Most of the time the signal does not retrigger and refresh until a scope button is pushed. If I increase the amplitude of the signal then it does cause a refresh as it passes through various levels. If I then decrease the signal then it doesn’t seem to trigger refreshes in the same way until the amplitude is quite small and then the display starts refreshing continuously.
I am not one of the developers of the application but I’d guess that there may be some sort of timing problem with the triggering getting re-armed at the right trigger level. Maybe there is some sort of time window where the re-arm is not done right and this window only occurs at this time-base and with full-screen display. Changing the buffering from full to single screen mode doesn’t seem to change behaviour which is a little odd as one would have expected that to change when the trigger gets re-armed.
Any developer watching who could comment? If not then I’ll try to have a look at the code in a few days when I have a bit more time.
I’ve just started looking at the code to see if I can understand what is going on to prevent 200uSec timebase from triggering properly when full screen is used.
Back in Feb 2013 the App went from 1.26 to 1.27 and the changes from Wildcat were merged in. I believe these helped quite a bit with stability of triggering and calibration.
One of these changes was in main loop (main.c) where a loopcount was introduced and some code added to update the trigger if this loopcount was reached.
</s> if ((TrgAuto>0)&&(_Mode!=SCAN)&&(_Mode!=AUTO)&&(_Mode!=SGL)) {
if(__Get(FIFO_START)== 0){ //check to see if not triggered w/auto trig on
loopcount++;
if (loopcount>TrigReset[_T_base]){ //after proper wait time, re-initialize trig
_Vt1=_1_posi; // set trig at signal zero point in hope to get device to trigger
_Vt2=_2_posi;
Update_Trig();
if (_Mode!=X_Y) Update_Mark();
loopcount=0;
}
}else loopcount=0;
}else loopcount=0;
<e>
This looks like a safety measure to get it going again if it stalls.
Now this seems to be intended to happen if __Get(FIFO_START) stays stuck at 0. However, if one looks carefully at the display when it is stuck then the first sample on the screen is actuallly changing even though the rest is not. A previous post had noted this as well. That makes me think that the test is not returning 0 all the time and so the Update_Trig() doesn’t get called.
Any button push on the scope does force some re-initialisation including Update_Trig and so the display then refreshes.
I’m not sure at the moment what this means in trying to fix this, but I thought I’d update whilst I continue to look at it in case anybody else has ideas.
Hello bobtidey,
Thank you for your time and help.
yes, that’s right. The first sample is updated.
I have no knowledge of the firmware. But since it only occurs in the time range 200us, I would imagine an overlap between the time base and trigger processing time. May be a problem with the Interruppt Priority?
(Sorry if I do not always express myself of course, with the English language I have minor problems)
In order to progress this further I needed to be able to build the app so I could try out some changes.
I first tried building using the latest Launchpad toolchain 4.7q32013. That built successfully. The hex file looked OK but although it loaded and showed the version screen it stuck there. I think somebody else had this problem and there didn’t seem to be an answer.
So I got the Sourcery toolchain 2011-03 that was used to build the original. After a bit of fiddling with the symlinks I have now built a hex which is identical to the supplied AP_G251 so that is a good sign.
I’ll continue using that toolchain to experiment with but does anyone have any idea why the Launchpad one doesn’t work? I did notice there isn’t a thumb2 lib in the Launchpad whereas there is one in the Sourcery, but I would have expected linker errors if that was used.
Regarding the issue with the 200uS timebase:
- At the beginning of the for loop in the Process routine:
CHANGE
if(((_T_base > 11)||(_Mode == SGL)||(freerun==1)||((_Mode==X_Y)&&(_T_base>9)))&&(_Status == RUN)){
TO
if(((_T_base > 10)||(_Mode == SGL)||(freerun==1)||((_Mode==X_Y)&&(_T_base>9)))&&(_Status == RUN)){
- In the “special case for in between sweep rates…” conditional in the Synchro routine
CHANGE
if ((_Status == RUN)&&(_T_base > 11)&&(_T_base < 14)&&(_Mode != SGL))
TO
if ((_Status == RUN)&&(_T_base > 10)&&(_T_base < 14)&&(_Mode != SGL))
- To blank out the noise at the beginning of the trace, in the Process routine:
CHANGE
if (_T_base < 17) // If sngl discard 4
{if (_T_base > 11)
{discard=4;
}else discard=1;
}else discard=0;
if (_Mode==SGL) discard=4;
TO
if (_T_base < 17) // If sngl discard 4
{if (_T_base > 10)
{discard=4;
}else discard=1;
}else discard=0;
if (_Mode==SGL) discard=4;
Brilliant, Wildcat. I was still working my way through trying to understand the timebase routines in process.
I made those changes and recompiled (changed version identifier to 1.30) and it works fine on 200uSec full screen mode.
I attach here a hex file for this and the two src files changed.