FREE Shipping in the USA by USPS Priority Mail!   Buy Now! - $129.50

Device Settings.

The USB Oscillopscope program operates satisfactorily on any PC on which Windows 2000/XP will run smoothly, i.e. at least Celeron 500MHz and 64MB RAM. In lesser computers, it is likely that the program will operate incorrectly. This is especially so in computers running Windows 98/ME, where upon pressing the start measurements button it changes its name to Stop when no measurement results are displayed. This is related to "slow" event processing of USB bus, i.e. the system just has not enough time to transmit all information within the fixed period.

To eliminate this undesireable behavior on slower compputers, it may be necessary to open the file usb_osc.ini, which will be on the hard drive where it was downloaded upon installation (by default in C:\Program Files\USB Oscilloscope) and find the lines:

[system]
usb_wr_timeout=50 - write timeout, ms
usb_rd_timeout=50 - read timeout, ms

These two parameters set the time interval in milliseconds - ms (timeout) within which the system has time to transmit (wr) and read (rd) data block from the device. Both timeouts are equal by default to 50 ms.

For example, a PC with an Athlon XP 1700MHz CPU and 512MB RAM running Windows XP transmits for 50 ms, while a PC with a Celeron 600MHz CPU and 192MB RAM running Windows XP the timeout value can be increased up to 100 ms though it runs for 50 ms. But with a Celeron 600MHz and 192MB RAM running Windows 98 the timeout values have to be at least 400-500 ms for normal operation.

These tests were also conducted for PC with Pentium 200 and 32MB RAM running Windows 98 where curiously it was seen that the program runs even in this computer, but the required timeouts were about 1000 ms.

Moreover, there are also two important system parameters in the usb_osc.ini:

usb_reset_timeout=50 - delay after reset, ms
wait_reset_trigger=300 - delay before reset of hang triggering, ms

Upon resetting the device, it is necessary to leave an interval to allow Windows to have time to configure the device, i.e. perform the standard start-up functions, allocate address and etc. The slower the computer, the longer these steps take, which it means that the delay will be longer as well. The usb_reset_timeout should be approximately equal to the communication timeout, i.e. when increasing any timeout it is necessary to increase the delay after reset.

The value of wait_reset_trigger determines the time allowed to reset the device if the triggering parameters are changed and the device shows no response, i.e. it hung. We can explain this parameter by the following example: if we turn on absolute triggering, set the level 5 V, maximum signal level 2 V, i.e. triggering condition will be never met because this device will be constantly in standby mode and no changes are shown on the screen. We change the triggering level up to 1 Volt, upon this change the program is waiting for wait_reset_trigger ms, if it is no response from the device that is expected in this case because it is waiting to execute an impossible triggering condition then the device is reset and measurements are completed. This delay is necessary to enable the device to response if triggering conditions are executable that is not often, e.g. every 250 ms. If previous triggering condition is executed all the same then the device will not be reset within wait_reset_trigger upon changing the triggering condition and it means that measurement will not be reset and the results will be displayed.

There is the additional line in the section [system]:

show_exchange_error=1

This line was added to inidcate some problems when operating the device and laptop as well as those related to the installed old driver version were detected. They are as follows: upon starting the program only one tab of logical analyzer was displayed because software determined it as a cut-off version due to the core driver (Jungo WinDriver) read data from the device incorrectly. As no error messages are displayed and we have not faced these problems in any of 10 computers where the device was tested and all the devices from the first lot were operated correctly as well then possibility of this error was not considered. This line was added to determine why, i.e. which error occurred within communication. If this device runs incorrectly or generally is out of operation then it is kindly recommended to set the value of this parameter to 1 and send me the error codes but if it runs satisfactorily then you can disable this function and set the value of the parameter to 0.