I've also noticed that it now takes several seconds for the trace to appear after the rest of the screen, even on fast timebase settings. I'm not sure if this is relevant to the above problem, but it is an observed difference in behaviour from the previous version.
P.S. I did perform factory reset and 0V trace alignment.
Triggering at 50ms per division and below
Re: Triggering at 50ms per division and below
Thank you for the testing. Please try the one attached with this post. The problems you mentioned were addressed in it.
Re: Triggering at 50ms per division and below
Thank you for the revised version, _much_ better. I can confirm that the button crash issue and the red measurements at fast timebase are fixed.
Now that I am able to use it without crashing I see two issues:
- At slow timebase settings it takes a long time before the unit will trigger (single trigger mode). I was puzzled at first but then realized that the s/w is probably sampling and filling 50% of the buffer before it will accept a trigger. I am not sure what the solution for this is? Maybe clear the buffer when the OK button is pressed to go from 'Hold' to 'Running' (and at startup) and then assume that it is 50% full of 0V until this data becomes populated? I noticed that the measurements are incorrect and Red again when switching on at slow timebase - I think this is probably due to the same thing (buffer not clear). Maybe you have already solved this problem on the DSO Shell.
- The trigger LED doesn't seem to be working. This might be my error because I didn't have it fitted previously but it does flash twice during startup, so I think it is correctly wired. Now the single shot triggering on slow timebases is available it becomes much more valuable (reason as above). As I said, it flashes twice during startup, but on my unit, doesn't light again at any timebase setting or trigger mode (even normal and auto).
Thank you for your effort to bring out this release successfully. I'm a bit surprised that you haven't had any other feedback yet, hopefully this will come as others try it.
Now that I am able to use it without crashing I see two issues:
- At slow timebase settings it takes a long time before the unit will trigger (single trigger mode). I was puzzled at first but then realized that the s/w is probably sampling and filling 50% of the buffer before it will accept a trigger. I am not sure what the solution for this is? Maybe clear the buffer when the OK button is pressed to go from 'Hold' to 'Running' (and at startup) and then assume that it is 50% full of 0V until this data becomes populated? I noticed that the measurements are incorrect and Red again when switching on at slow timebase - I think this is probably due to the same thing (buffer not clear). Maybe you have already solved this problem on the DSO Shell.
- The trigger LED doesn't seem to be working. This might be my error because I didn't have it fitted previously but it does flash twice during startup, so I think it is correctly wired. Now the single shot triggering on slow timebases is available it becomes much more valuable (reason as above). As I said, it flashes twice during startup, but on my unit, doesn't light again at any timebase setting or trigger mode (even normal and auto).
Thank you for your effort to bring out this release successfully. I'm a bit surprised that you haven't had any other feedback yet, hopefully this will come as others try it.
Re: Triggering at 50ms per division and below
Thank you again for the testing.
It is true that the trigger starts to work only after half of buffer has been filled with new samples. This is to make sure correct pre-trigger data can be captured. At slow timebase this period becomes noticeably long. In the Shell "Holdoff" is displayed during this period to let user know trigger is not available.
The LED issue should be a firmware bug. We'll check.
It is true that the trigger starts to work only after half of buffer has been filled with new samples. This is to make sure correct pre-trigger data can be captured. At slow timebase this period becomes noticeably long. In the Shell "Holdoff" is displayed during this period to let user know trigger is not available.
The LED issue should be a firmware bug. We'll check.
Re: Triggering at 50ms per division and below
Thank you.
The "Holdoff" solution sounds good. I'm not sure if it would still be worth clearing the buffer (0V) and measurements to further indicate that a new run has started, just a thought.
The "Holdoff" solution sounds good. I'm not sure if it would still be worth clearing the buffer (0V) and measurements to further indicate that a new run has started, just a thought.
Re: Triggering at 50ms per division and below
I have a question for gyro,
How frequently does the new version of the firmware lock up? I'm trying to decide if I should wait to update.
I have had the Chinese characters and JYEtech appear on the bottom of the screen one time.
I have version-061 firmware.
How frequently does the new version of the firmware lock up? I'm trying to decide if I should wait to update.
I have had the Chinese characters and JYEtech appear on the bottom of the screen one time.
I have version-061 firmware.
Re: Triggering at 50ms per division and below
The latest of the two test versions in this thread doesn't appear to crash (the first one did). On very slow timebases it can appear to freeze of Normal and Single trigger modes simply because it takes a long time in pre-trigger and post trigger. JYE still need to fix the trigger LED and implement the "Holdoff" indication.
To be fair, I didn't see any crashes with Version 060. I didn't bother with 061 as it didn't incude any functionality change, just support for a new graphics controller that isn't fitted to my unit. If you are suffering from lots of crashes then you may be suffering from a hardware or power supply fault.
Should you install the test version? Well, it's up to you. Nobody other than me has provided any feedback so I don't know how many others have tried it.
My opinion is that if nobody is prepared to try the new version with the improved trigger functionalty (which several people have been asking for!), then we have no excuse to complain if there is a bug or expect a fix after it is released.
To be fair, I didn't see any crashes with Version 060. I didn't bother with 061 as it didn't incude any functionality change, just support for a new graphics controller that isn't fitted to my unit. If you are suffering from lots of crashes then you may be suffering from a hardware or power supply fault.
Should you install the test version? Well, it's up to you. Nobody other than me has provided any feedback so I don't know how many others have tried it.
My opinion is that if nobody is prepared to try the new version with the improved trigger functionalty (which several people have been asking for!), then we have no excuse to complain if there is a bug or expect a fix after it is released.
Re: Triggering at 50ms per division and below
I have upgraded my DSO138 with mixed results.
My USB to RS232 bridge arrived from MPJA.com today. Their part # is 12389 CB. It installed itself automatically into Windows 10 when connected.
I made a cable to connect the bridge to the scope. Counting the ground pin on either connector as pin 1 it was very straightforward, 1 to 1, 2 to 2 and 3 to 3.
I had previously extracted the -065 hex file from the .rar file. Could this be a zip file? I had to find a program to extract .rar
The upgrade to the firmware worked as the instructions said with one exception. Between the screens shown in Fig. 4 and Fig. 5 I was presented with a screen that asked if I wanted to remove protection. I bravely said yes and the upgrade continued as per instructions.
The sweep speeds 50 mS and slower now recognize the trigger. However the system crashes if the [+] or [-] buttons are held for a long time as is required for large changes to the trigger level or the horizontal position. The reset button does restore correct operation without the need to power off.
I noticed the horizontal position centering has the some minor bug as the trigger centering. If the position is not changed with the [+] or [-] buttons after centering it will reset to the last position before centering after a reset. And of course now I am getting a lot of resets.
I hope this information will help the JYE Tech crew improve the firmware.
My USB to RS232 bridge arrived from MPJA.com today. Their part # is 12389 CB. It installed itself automatically into Windows 10 when connected.
I made a cable to connect the bridge to the scope. Counting the ground pin on either connector as pin 1 it was very straightforward, 1 to 1, 2 to 2 and 3 to 3.
I had previously extracted the -065 hex file from the .rar file. Could this be a zip file? I had to find a program to extract .rar
The upgrade to the firmware worked as the instructions said with one exception. Between the screens shown in Fig. 4 and Fig. 5 I was presented with a screen that asked if I wanted to remove protection. I bravely said yes and the upgrade continued as per instructions.
The sweep speeds 50 mS and slower now recognize the trigger. However the system crashes if the [+] or [-] buttons are held for a long time as is required for large changes to the trigger level or the horizontal position. The reset button does restore correct operation without the need to power off.
I noticed the horizontal position centering has the some minor bug as the trigger centering. If the position is not changed with the [+] or [-] buttons after centering it will reset to the last position before centering after a reset. And of course now I am getting a lot of resets.
I hope this information will help the JYE Tech crew improve the firmware.
Re: Triggering at 50ms per division and below
Are you using the second version posted in this thread - a few posts ago (Sun 03 Sept)?
I had exactly the same problem with the buttons with the first one. JYE added the above one to fix it.
I had exactly the same problem with the buttons with the first one. JYE added the above one to fix it.
Re: Triggering at 50ms per division and below
Thanks Gyro,
It works much better now.
I had checked the filename of the file I downloaded earlier against the name in the Sept 02 post and they matched. I didn't realize they would issue a new version with the same name.
Today I also replaced the reverse voltage protection diode with a P-channel mosfet. It reduced the voltage drop from 0.8 volts to 0.01 volts. This will help to suck the last drops out of a 9 volt battery.
I used a NTD2955
https://electronics.stackexchange.com/q ... nel-mosfet
It works much better now.
I had checked the filename of the file I downloaded earlier against the name in the Sept 02 post and they matched. I didn't realize they would issue a new version with the same name.
Today I also replaced the reverse voltage protection diode with a P-channel mosfet. It reduced the voltage drop from 0.8 volts to 0.01 volts. This will help to suck the last drops out of a 9 volt battery.
I used a NTD2955
https://electronics.stackexchange.com/q ... nel-mosfet