Owon AG1012F Arbitrary Waveform Generator

[TomC]

Arb part 5 (Cut wave)
-----------------------------------

On this post I'd like to continue to explore the editable arbitrary (Arb) waveforms. In particular, capturing a waveform on an Owon DSO and playing it back on the AG1012F.

You can find the Owon specs and some of Owon's instructions verbatim from the manual on post 39.

The basic settings and connections are the same as used in previous posts. Other settings can be read from the AG1012F & SDS7102 images.

             ------------------------------------------------------------------------

The Owon manual has some information on how to capture waveforms on their SDS DSOs and how to play them back on their AWGs. Here is part of that information verbatim from the manual:

To recall wave file

This function can read the waveform file with suffix of (*.ota) which is cut from SDS series oscilloscope manufactured by OWON and saved to USB device or cut by the software of OWON oscilloscope. Then ARB waveform generators can output the same signal as the cut wave.

Tips:

1. Normally the frequency, amplitude, and offset of the recalled wave are the same as the wave being cut, but when the frequency, amplitude, and offset are set out of the limit range, then the generator would use the current parameter, which leads to the recalled wave not totally the same as the cut wave.

2. The max data number of AG1012F AG1022F ARB is 8192. When the wave cut from oscilloscope contains data number more than 8192, AG1012F and AG1022F will compress data. On the contrary if the data number is less than 8192, AG1012F and AG1022F will use linear interpolation.

3. The max data number of AG2052F, AG2062F ARB is 1000000. When the wave cut from oscilloscope contains data number more than 1000000, generators will compress data. On the contrary if the data number is less than 1000000, generators will use linear interpolation.

             --------------------------------------------------------------------------


On this post I'll try to illustrate how to use this feature using my Owon SDS7102 DSO to cut a waveform and my AG1012F to play it back. For the signal source I'm going to use an old color bar generator & vector scope. First I'll use the DSO to look at the generator's video output while it is setup to output a 3 x 3 color bar display. Then I'll try to cut a single line of video including the horizontal sync pulse and store it in my thumb drive. Finally I'll transfer the thumb drive to my AG1012F and play back the file.


Attachment #1 -  This is the output of the color bar generator showing the last part of the vertical sync pulse and the first few lines of video. The SDS7102 has a video trigger but in this case the trace wasn't very stable, perhaps because this color generator doesn't provide a strict NTSC signal. So, instead, I'm using a pulse trigger of appropriate width to lock unto the vertical sync pulse.


Attachment #2 -  Here I moved the trace to the left and changed the time base to enlarge the line of video that I plan to cut. Notice that the current SDS7102 sample rate is 100MS/s and the line of video that I plan to cut is about 63 microseconds. So the approximate number of data points on this waveform should be 63 x 100 = 6300. According to Owon if the number of data points is less than 8192 they use linear interpolation, which I assume means they will increase the number of data points to 8192. So I'm doing this on purpose to see how well this mechanism performs.


Attachment #3 -  This is the screen you get right after selecting "CutWave". As indicated by the pop up instructions you can now move the cursors to identify the area you want to cut and then press "Save" when you are ready. In this image I have already placed the cursors where I want them, and as can be seen the area to be cut is 63.1 microseconds long, so the video line frequency is 15.85kHz. I'm going to name this file: 6300p_v_line, as a result the file stored in the thumb drive should be 6300p_v_line.ota.


Attachment #4 -  This is the same as #3, but I have changed the SDS7102 Acquire Length so that the sampling rate is 1GS/s. So the approximate number of data points on this waveform should be 63 x 1000 = 63000. According to Owon if the number of data points is greater than 8192 they use compression, which I assume means they will reduce the number of data points to 8192. So I'm doing this on purpose to see how well this mechanism performs. I'm going to name this file: 63000p_v_line, as a result the file stored in the thumb drive should be 63000p_v_line.ota.

The next thing I want to do is find out exactly how many data points the AG1012F sees in these files, so I'm going to pretend that I want to edit them to get the AG1012F to display the number of points on the screen.


Attachment #5 -  This is the screen I got when I tried to edit 6300p_v_line.ota, the only thing that is right is the number of points. Don't despair, this is another quirk with a workaround, you need to reboot the AG1012F and immediately after try the edit again. If you do something else first, like playback a file, you'll probably get this quirky screen again.


Attachment #6 -  This is the screen I got after rebooting and then trying to edit 6300p_v_line.ota again. This looks OK to me, it doesn't show the fine details of the signal, like the 3.58MHz color modulation, but hopefully this will show up when we play it back. One thing we learn is that Owon didn't change the number of data points to 8192 as one of their tips seems to imply. Perhaps what they mean is that this linear interpolation takes place when the file is played back.

Before I leave this screen I'm going to press "Store" and save this file again with the same name. This should produce a file with a .bin extension. Files with a .ota extension cannot be edited with the Ultrawave software, so in effect, what I'm going to do here is convert the file to the .bin format which is supported by Ultrawave.


Attachment #7 -  This is the screen I got when I tried to edit 63000p_v_line.ota. This looks OK to me, again, it doesn't show the fine details of the signal, but this should show up when we play it back. One thing we learn is that Owon did change the number of data points to 8192 as one of their tips implied. So the compression that they talk about apparently happens when the file is created. Note that .ota files behave as files created using interpolation ON, so if you plan to edit one of these the rules I talked about on the last post apply.

Before I leave this screen I'm going to press "Store" and save this file again with the same name to get an additional file converted to the .bin format.


Attachment #8 -  This shows the four new files as they appear in the thumb drive. What I find interesting is the different file sizes. In the case of the 6300 points file the file size increased when it was converted from .ota to .bin. In contrast, for the 63000 points file the file size drastically decreased. I'm not quite sure what this all means, but I'm attaching all 4 files in case someone wants to try and decode them and give me the answer!


Attachment #9 -  This is the setup to output 6300p_v_line.ota. The AG1012F extracted the setup values like frequency and amplitude from the file since they are within the limits of operation of the AG1012F.


Attachment #10 -  This shows the output of the color generator on Ch1 and the output of the AG1012F for #9 on Ch2. I used single trigger to get the waveforms to match up as close as possible for comparison.


Attachment #11 -  This is an expanded view of #10 to show the detail of the 3.58MHz color modulation.


Attachment #12 -  This is the same as #10 but this time the AG1012F is setup to output 63000p_v_line.ota. I don't see much difference, and the expanded view looks just like #11. I also played back the .bin versions of the files with nearly identical results. However, note that when the .bin versions of the .ota files are played back the AG1012F defaults to the previous setup. In contrast, as mentioned above, the .ota files contain setup values that the AG1012F will use instead of the previous setup values if possible.
 
 

[TomC]

Arb part 5 (Cut wave), Additional Thoughts
-------------------------------------------

On this post I'd like to add some additional information and reflections related to the previous post (50).

                  ----------------------------------------------------------------------

On post 50 the following arb waveform files were created:

6300p_v_line.ota     6.22kB (63.1 microseconds captured at 100MS/s for a total of 63.1 x 100 = 6310 data points)

6300p_v_line.bin    12.37kB

63000p_v_line.ota   61.68kB (63.1 microseconds captured at 1GS/s for a total of 63.1 x 1000 = 63100 data points)

63000p_v_line.bin   16.05kB


The .ota files were created with my Owon SDS7102 DSO. These files conform to a format that can be interpreted by Owon AWGs, for example, the AG1012F and the AG2062F. However, the number of data points that can be rendered by an Owon AWG vary depending on the model number, for example, the AG1012F has a limit of 8192, while the AG2062 has a limit of 1000000. So it wouldn't make sense for any interpolation or compression of the .ota file data points to occur when they are created by the Owon SDS DSO. This becomes evident to me when I consider that at the time of creation there is no way to know which Owon AWG model will be used to play the files back.

Based on the above reasoning, I now believe that the 63000p_v_line.ota Arb file actually contains 63100 data points even though when opened for editing on the AG1012F the edit screen only shows 8192 data points. I also believe, although I can't prove it, that if the same file was opened on an AG2062F the edit screen would show all 63100 data points. Perhaps this also helps explain why the file size decreases from 61.68kB to 16.05kB when converted to a .bin file. Consider that in this case, the conversion is being done by an AG1012F which is limited to 8192 data points. To me this is evidence that the .bin version of the file has probably been compressed to 8192 data points

As further corroboration of this hypothesis, we can also look at the ratio of the file sizes compared to the ratio of the number of data points that I suspect each file version contains. For the file sizes we have a ratio of 16.05/61.68 = 0.26, and for the data points we have a ratio of 8192/63100 = 0.13. These numbers make sense if we assume that .bin files are twice the size of .ota files with the same number of data points. This assumption is corroborated by the file sizes of 6300p_v_line.bin and 6300p_v_line.ota. Since the AG1012F can handle more than 6310 data points, in the case of these two files I don't see a reason to suspect that the number of data points was changed by converting the .ota version of the file to .bin. With this in mind, I think that comparing the 0.26 ratio to the 0.13 ratio strongly indicates that the change in file size exactly corresponds to the change in the number of data points.

To further simplify, let's project the size of a .ota file equivalent to 63000p_v_line.bin, if we assume that it should be half the size we get 16.05/2 = 8. If we now calculate the ratio of the 63000p_v_line.ota and the projected .ota file we get 8/61.68 = 0.13. Exactly the same as the ratio of 8192/63100 = 0.13.

As for any linear interpolation or compression related to .ota files as mentioned in the Owon tips, I now believe that any implementation of this feature would have to occur on the fly as the files are being played back. As I explained above, I see no evidence that the files themselves contain data points that have been interpolated or compressed.

[TomC]

Utility
------------------

On this post I'd like to explore the "Utility" interface and function.

First, let's review the Owon specs and some of Owon's instructions verbatim from the manual:



Phase Deviation                  0 - 360°


External Reference Clock Input
----------------------------------------------------------------

Impedance                        1 k ohm, AC coupled

Requested Input voltage swing    100 mVp-p to 5 Vp-p

locking range                    20 MHz ± 35 kHz


External Reference Clock Output
-----------------------------------------------------------------

Impedance                        50 k ohm, AC coupled

Amplitude                        5 Vp-p, access 50 ohm


Some of the instructions from the manual (here I only listed what I though may not be obvious)
---------------------------------------------------------------------------

To Set the Output Load

For either of CH1 Output and CH2 Output on the Front panel, the Generator has a built-in 50Oseries impendence. If the actual load does not match the set one, the displayed amplitude and offset are incorrect. This function is used to match the displayed voltage with the expected one.


The default settings of the system are as follows:

Output                        Default
-------                       ---------
Function                      Sine Wave
Frequency                     1 kHz
Amplitude/Offset              1 Vp-p / 0 Vdc

Waveforms                     Default
---------                     ---------
Frequency                     1 kHz
Amplitude                     1 Vp-p
Offset                        0 Vdc
Duty Cycle of Square          50%
Symmetry of Ramp              50%
Pulse Width of Pulse          200 us
Duty Cycle of Pulse           20%

Modulation                    Default
----------                    ---------
Carrier                       1 kHz Sine Wave
Modulating                    100 Hz Sine Wave
AM Depth                      100%
FM Deviation                  100 Hz
PM Phase Deviation            0°
FSK Hop Frequency             100 Hz
FSK Frequency                 100 Hz
Source                        Internal

Sweep                         Default
-------                       ---------
Start/Stop Frequency          100 Hz/1 kHz
Time                          1 sec
Mode                          Linear

Burst                         Default
-------                       ---------
Frequency                     1 kHz
Count                         1 Cycle
Period                        1 sec
Phase                         0°

Others                        Default
-------                       ---------
Brightness                    95%
Separator                     Comma
Screen Saver time             100 minutes
Load                          High Z
Phase Deviation               0°
Clock Source                  Internal
Channel Output Control        Off


To Set the Clock Source

The waveform generator provides an internal clock source and also accepts external clock source input from the [Ref Clk/Counter In] connector at the rear panel. It can also output a clock source from the [Ref Clk Out] connector for other device to use.

Note: The amplitude of the [Ref Clk/Counter In] input signal must be over 1 V.

             ------------------------------------------------------------------------

With the above in mind let's first review the "Utility" interface.  The basic settings and connections are the same as used in previous posts. Other settings can be read from the AG1012F & SDS7102 images.


Attachment #1 -  This is the main Utility menu, there are 4 choices and we have already covered the Counter on a previous post.


Attachment #2 -  These are the Display setup choices. 95% is the brightness default and I haven't found a reason to use a different setting. Note that some of the possible settings cause the DC/DC converter associated with this feature to emit an annoying noise.

The default for separator is comma, or you can choose space or nothing (off). I prefer nothing. By default the screen saver pops up after 100 minutes of inactivity. I have no use for that feature either, so I turned it off.


Attachment #3 -  These are the Output setup choices. Here you set the load for either channel, set the phase deviation if desired, and set the baud rate. Note that BaudRate is not used on current units, it appears that Owon did use a serial port on early units.

You can enter a load from 1 to 10k ohms or choose High Z by pressing the button. This will just change the button label and hide the load value in the center of the screen as shown in attachment #4.

Note that the generator always uses a 50 ohm series impedance regardless of the setting. It uses the user's input to predict the output voltage based on a potential divider calculation. For example, if you tell it that the load is 50 ohms and that the waveform amplitude should be 2Vpp, the generator will output 4Vpp. This is because it expects that by applying 4Vpp across two 50 ohm resistors in series the voltage across the load will be half of 4Vpp (2Vpp). On the other hand, if you tell it that the load is High Z, then the generator will output 2Vpp. The reason is that in this case the generator expects the load to be greater than 10k ohms, and therefore, the voltage drop across its internal 50 ohm resistor should be negligible. So nearly the full 2Vpp should appear across the load.


Attachment #4 -  This is the way the screen appears when the load is set to High Z.


Attachment #5 -  Here you can set the PhaseDEv between the two channels to any value between 0 - 360° or turn the feature off by pressing the button. In that case the screen appears as in attachment #6. The default PhaseDev value is 0°.

I would have expected that when the phase is set to 0° or turned off the signals at the output of the two channels, specially if identical, would be in phase. However, this isn't always the case. They are in phase at low frequencies, but as the frequency increases the phase deviation between them also increases. I suspect that this will probably vary between units due to component tolerances. Attachment #7 & #8 show the phase deviation between the two channels at 1kHz and 10Mhz when the PhaseDev is either off or set to 0°.

Attachment #6 -  This is the way the utility screen appears when the PhaseDev is set to off.


Attachment #7 -  This shows the DSO image of the CH1 & CH2 signals when the AG1012F outputs are set to standard sine wave at 1kHz.


Attachment #8 -  This shows the DSO image of the CH1 & CH2 signals when the AG1012F outputs are set to standard sine wave at 10MHz.


Attachment #9 -  This shows the utility screen PhaseDev setting required to correct the CH1 & CH2 phase deviation depicted on #8.


Attachment #10 -  This shows the DSO image of the CH1 & CH2 signals after changing the AG1012F setting as shown on  #9.


Attachment #11 -  This is page 1 of the System setup choices. Here you can select English or Chinese, whether you want to retain the last setup choices the next time you power on or just go back to default values, and there is also a button to go back to default values on demand.

Attachment #12 -  This is page 2 of the System setup choices. Here you can able or disable beeps that among other things are supposed to wake you when you thoughtlessly ask the unit to do thing outside of its capabilities. I don't get enough sleep as it is, so this is one feature I wouldn't miss if it was forever silenced.


Attachment #13 -  This is what you get if you press "Sys  info".


Attachment #14 -  This is what you get if you try to change the clock source to external but don't have, according to Owon, a suitable clock signal connected to the "Ref Clk/Counter In" connector at the rear panel.

I don't have another signal generator that provides a 20MHz clock at the amplitude level that Owon requires. So to test this feature I looped the "Ref Clk Out" to the "Ref Clk/Counter In" at the rear of the unit. You would think that the clock Owon provides for other generators to synchronize on would also be appropriate for their own generators. So the next two attachments show how this turned out.


Attachment #15 -  This shows the DSO image of the "Ref Clk Out" on Ch1 and an AG1012F output set to standard sine at 10MHz on Ch2. The DSO is triggered on Ch2 and the persistence is set to 5 seconds to catch any mis-synchronization between the two signals. When this image was captured the "Ref Clk Out" was looped to the "Ref Clk/Counter In" at the rear of the unit but the clock source was set to "internal".


Attachment #16 -  This is the same as #15 but in this case the clock source is set to "external".

Not that I think I'll be using this feature much, if ever, but nevertheless I'm not impressed! I sort of expected this to work flawlessly!


                -------------------------------------------------------------------------------


I think this is it as far as the features available via the unit's user interface! 

Unless I remember or one of you remind me of something I missed! Otherwise, I think I'll be turning my attention to the PC software, mainly, Ultrawave.

[TomC]

Utrawave, first impression
---------------------------


The PC software available for the Owon AWGs is a version of Ultrawave. Reading the Owon documentation I get the impression that they feel/claim it has the following capabilities:

1) Download Arb files from the Owon AWG or Upload Arb files to the Owon AWG.

2) Edit Arb files created on the Owon AWG.

3) Create new Arb files that can be interpreted by the Owon AWG.

4) Control the operation of the Owon AWG via a Remote Control Panel.

5) Control the operation of the Owon AWG using ACPI via a Command Line Control Panel.

For the last few days I've been giving these features a workout, my impression is that to a certain degree, but with unusual or unexpected limitations, they can do all of the above. However, in my opinion, compared to other software designed to perform similar tasks, this software is rudimentary, lacks basic features, and for those reasons is nearly useless.

For example, the editor doesn't show the cursor position, so if you click to set a data point the only reference you have is the graduations on the grid. The only way to get some precision is to use Point Edit, where you can enter a data point and a particular voltage level. However, you would think that this feature would also give you the current value of the data point, like when editing Arbs on the AWG itself, but nothing, so I guess you are supposed to know beforehand.


Attachment #1: This is a version of the 361p_sine_x10.bin after I used Point Edit to create the spike. Notice there is no cursor position anywhere. So there isn't a way to know the exact voltage of any of the data points, or exactly where the data points are located. Also, the data points start with 0 on this editor, so one more confusion factor since on the AWG itself they start with 1.


OK, I'll try to post some more detailed tests soon!

[TomC]

Ultrawave - Download & Upload
-----------------------------

ON this post I'd like to explore the communications and file transfer functionality provided by the Ultrawave PC Software.


Attachment #1 -  Port-settings dialog. This is normally the first screen you want to visit if you intend to download/upload arb files from/to a particular Owon AWG. It lists the AWGs by serial number, and if you happen to have an OWOn SDS DSO connected to the USB bus, as in this case, its model number will also appear on the list. The dialog also allows you to select LAN instead of USB, the Owon AG-S series (single channel) AWGs come with LAN ports.

I've tried selecting the DSO to see if anything would work, but basically nothing useful, under certain circumstances it's possible to use the ACPI console, but you also have to involve the DSO PC software.


Attachment #2 -  Get Data dialog. This is the next screen you would want to visit. If you click "GetFiles", like I did here, you'll get a list of the files present in the AWG's internal storage or thumb drive, whichever one you were accessing last via the AWG's UI. There isn't a way to change the drive via Ultrawave (or SCPI). As can be seen the list only shows file names, no size, no drive. The list you see here happens to be from my thumb drive.


"DownLoad"
----------
Supposedly you can now select a file and press "Download", and if everything goes well a copy of the file will be stored in the "Download Path:" and displayed on the edit window ready to be edited. However, I haven't been able to download files from the thumb drive successfully, although a few times I thought I did. As it turned out, this happened only for files that were previously downloaded from the internal storage and were subsequently fetched from the cache when I thought I had downloaded them again from the thumb drive.

So if you want to edit a file that's only present in the thumb drive, you can either do a copy and paste at the AWG to get a copy of it in the internal storage, or you can move the thumb drive to your PC and access it via Ultrawave's File menu.

Only files with a .bin extension can be downloaded successfully. However, the AWG is capable of playing back files that don't have a proper extension if they are otherwise formatted the same as a .bin file. So if you want to download one of these files to the PC using Ultrawave you must first rename it using the AWG UI.

"Delete"
---------
As expected, if everything goes well, the selected file disappears from the list and the AWG screen (if you were watching the file system). But again, if the list you are viewing is for the thumb drive, delete doesn't work. By the way, I've tried to delete the phantom files using this interface, but no dice!

"UpLoad" & "Upload Local File"
-------------------------------

These two are very similar in that they will upload a file stored in the PC to the AWG. By default the program looks for the file in the "Download Path:". In the case of "Upload Local File" the user is presented with an explorer window (see attachment #3) and allowed to select a file to upload, in the case of "Upload" the filename is presumed to be the name of the file in the Edit window.

There isn't a way to select the destination AWG storage, and regardless of which storage was accessed last via the AWG's UI, the upload always lands in the AWG's internal storage. Filenames consisting of more than 12 characters including the extension are truncated and only the first 12 characters are passed on to the AWG as the filename. So, for example, if you upload a file named "1234567890.bin", the file received at the AWG will be named "1234567890.b" (See attachment #4).

Although the extension isn't .bin, the AWG doesn't seem to care, and can play it back or whatever as if it was a regular .bin file. However, if you want to later on download this file back to the PC using Ultrawave, you'll get a "Format not supported for file:" error. To get around this you'll have to rename the file so that it has the complete .bin extension.


Attachment #3 -  Explorer window used to select the local file to be uploaded.


Attachment #4 -  Some files with truncated filenames.


         ------------------------------------------------------------------------


I'm not happy with all these quirks and unpolished or unfinished features. I think this state of affairs is a little embarrassing and definitely needs some work!

[rf-loop]

Attachment #10 -  This is what #8 at 10MHz looks like on the DSO. I'm using infinite persistence to try to catch spikes that occur infrequently, but I don't see anything.


Attachment #11 -  This is what #8 at 9.999999MHz looks like on the DSO. I'm using infinite persistence to try to catch spikes that occur infrequently, I can clearly see that they occur once in a while thanks to the marvels of DDS technology.

I think here need note (you of course  know it but all do not...) that Arb Nyquist limit is 62.5MHz (125MSa/s)  and your spike is narrow.

Then other thing. If example 8192points is one Arb cycle and cycle frequency is 10MHz, needless to say it need "jump" over lot of points because there is 12ps for one point  if read all points.  Because Arb 125MSa/s means that it use 8000ps for one step.  So, many times it need jump over your spike. With some frequencies it may disappear and with some frequencies it appears some times.  It need run this "jumping" so that it also can adjust output frequency in used system what is fixed clock Arb. You just find Basic fundamental physical limits of this AWG. This happends, (I believe) with all  Arb generators what use this simple method.

[TomC]

Attachment #10 -  This is what #8 at 10MHz looks like on the DSO. I'm using infinite persistence to try to catch spikes that occur infrequently, but I don't see anything.


Attachment #11 -  This is what #8 at 9.999999MHz looks like on the DSO. I'm using infinite persistence to try to catch spikes that occur infrequently, I can clearly see that they occur once in a while thanks to the marvels of DDS technology.

I think here need note (you of course  know it but all do not...) that Arb Nyquist limit is 62.5MHz (125MSa/s)  and your spike is narrow.

Then other thing. If example 8192points is one Arb cycle and cycle frequency is 10MHz, needless to say it need "jump" over lot of points because there is 12ps for one point  if read all points.  Because Arb 125MSa/s means that it use 8000ps for one step.  So, many times it need jump over your spike. With some frequencies it may disappear and with some frequencies it appears some times.  It need run this "jumping" so that it also can adjust output frequency in used system what is fixed clock Arb. You just find Basic fundamental physical limits of this AWG. This happends, (I believe) with all  Arb generators what use this simple method.

Thanks for further explaining some of the inherent characteristics of DDS!

In retrospect, I think that summarizing it as an effect of the marvels of DDS left a few things unsaid for those not familiar with it!

[TomC]

Ultrawave - Editing Arb Files
------------------------------


ON this post I'd like to explore Ultrawave's capabilities and performance while creating and/or editing Arb files, including files created using the Owon AWG's user interface.

In addition to the limitations mentioned on post 53, there are a number of quirks that at the very least can be confusing. So I'm going to try to illustrate some of these quirks as we go along.


Attachment #1 -  This is a sketch showing the data point voltages required to create either a 2Vpp 17 point sine wave (interpolation ON), or a stair up/stair down 2Vpp signal using the same data points (interpolation OFF). I plan to use these two signals to compare the Ultrawave and AG1012F UIs.


Attachment #2 -  This is a hex dump of a file created using the AG1012F UI based on #1. This file was created with interpolation OFF, so it should display and output the stair up/stair down 2Vpp signal version.

To help me evaluate and understand the behavior of the two UIs I decided it was time to try to decode the file format. So the comments in red is what I came up with. Note that in the examples I converted the native endianness to conventional, left to right, most significant to least significant hexadecimal representation, because, at least for me, is easier to visualize and do math.


Attachment #3 -  This is how #2 displays on the AG1012F screen. Notice that the AG1012F uses the lowest & highest voltage data point values on the top line of the hex dump to scale the Y axis of the graph. In addition, it uses the value of byte 00000000 to decide how to render the plot. In this case, since the value is 00, it renders the plot with interpolation OFF.

Next, I want to see what happens when I download or open this file using the Ultrawave PC software.


Attachment #4 -  This is how Ultrawave renders #2. The screenshot was taken immediately after downloading the file from the AG1012F.

Notice that the Y axis did not get scaled based on the values on the top line of the hex dump, instead, it defaults to 20Vpp. In addition, the plot wasn't rendered based on the value of byte 00000000 (interpolation OFF). As it turns out, there isn't an option to change the way Ultrawave renders the plot, so regardless of the value of byte 00000000, the plot is always rendered by connecting the data points with straight lines. The only other option is to display just the data points (red dots) without any interconnecting lines.

There is an interesting feature on the edit menu, "Rework", click on this and you are allowed to alter the number of data points and the scale of the y axis, a functionality that is not available when editing Arbs via the AG1012F UI.

Next, I'm going to save this file without making any alterations and see if anything changes when I do a hex dump using my hex editor.


Attachment #5 -  This is the hex dump of what used to be #2 after clicking "Save" on Ultrawave.

Notice the new values on the top line of the hex dump, if you convert these using the example on #2 you should get +10000mV & -10000mV. In addition, the file name placeholders were set to 00, however, I think the value of these is irrelevant.

Next I want to upload this file to the AG1012F and see it's rendered differently. Note that when the file you upload to the AG1012F has the same name as an existing file, the existing file is overwritten. Keep this in mind if you want to preserve both files because there is NO warning.


Attachment #6 -  This is how #5 displays on the AG1012F screen. Notice that the Y axis reflects the new values, and although difficult to see because of the scaling, the plot still depicts the stair up/stair down 2Vpp signal.

Next I want to use the "Rework" feature and change the Y axis scale back to 2Vpp.


Attachment #7 -  This is how Ultrawave renders #5 after changing the voltage from 10000mV to 1000mV. This causes the Y axis scale to change to 2Vpp. The "Rework" dialog disappears after you click OK, but I re-invoked it to include it in the screenshot just to show how it looks.

Since this is supposed to be a stair up/stair down 2Vpp waveform, I think the straight lines between the data points would be very confusing for the user when trying to edit the waveform. There isn't a way to change the way these lines are rendered, so perhaps it would be easier to get rid of the lines altogether. To do this you can use the "Format" menu, or click the toolbar icon with the 3 dots in a delta formation.


Attachment #8 -  This is how Ultrawave renders the data points by themselves. I added the circles around the very small red dots that represent the data points because I thought they would be difficult to spot when this image is viewed.

Next, I'm going to save this file without making any further alterations and see if anything changes when I do a hex dump using my hex editor.


Attachment #9 -  This is the hex dump of what used to be #5 after clicking "Save" on Ultrawave.

Notice the new values on the top line of the hex dump, this is the same we had on #2. So the only difference between the two hex dumps is in the file name placeholders which are now set to 00.

I uploaded this file back to the AG1012F and the graph and plot is identical to what we got on #3.

Finally, I want to create a new file with the same data points using the Ultrawave UI. Primarily, I want to see how it displays, and what happens to byte 00000000.


Attachment #10 -  This is how the screen looked after I entered the last data point, 16 aka 17. Notice that data point 0 is at -1V. At first I thought I made a mistake when I first entered this data point, because, when I went back and re-entered it, it worked correctly. But NO, no mistake, when you enter data point 0 the first time, for some reason, it doesn't register. However, it works every time when you come back, after entering other data points, and re-enter it.


Attachment #11 -  This is how the screen looked after I re-entered data point 0 (aka 1).

After this I saved the file and got a hex dump, the hex dump was identical to #9. So although Ultrawave renders the plot as if interpolation was ON when you create a file from scratch, the file it produces indicates interpolation is OFF. I uploaded the file to the AG1012F and as expected it's rendered the same as #3.

                        --------------------------------------------------------------

OK, this is it for today! I need to catch some sleep! But I'm not done yet with Ultrawave, I don't want to miss any additional quirks that may be hiding in plain sight!

[TomC]

Ultrawave - Creating Arb Files
------------------------------


ON this post I'd like to explore Ultrawave's capabilities and performance while creating Arb files from scratch. This time I want to create more complex Arbs and try to use some of the other drawing tools offered by Ultrawave.


Attachment #1 -  This the way the edit window looks after creating a 361 point sine wave using an approach similar to what I used on post 40 to create the 361p_sine_X10.bin Arb described in it.

The data point values were entered using "Point Edit". As I did on post 40 via the AG1012F UI, I only entered the values for data points 0, 10, 20 ... 360. In a way similar to the AG1012F, Ultrawave also automatically fills-in the values for the data points in between.

However, I've noticed a couple of differences in the way that the two UIs handle in between data points. In the AG1012F this feature only worked when skipping data points by certain multiples, for example 10 or 100. Also, the data point values for the first skip didn't interpolate correctly and had to be re-entered manually at some point. In contrast, Ultrawave always seems to automatically fill in the values in between with what appears to be straight lines regardless of the number of data points skipped. In addition, this mechanism also works correctly for the first skip.

While working on this file I also discovered an easier workaround for the problem with the value for data point 0 not registering when it's first entered (see the original description of this problem on post 57). Now, to get it to register correctly every time, I just click OK twice when I first enter its value.


Attachment #1a -  This is the same as #1 but for this screenshot I changed the format to "Data Point".

Next I'm going to compare the hex dump of 361p_sine_X10.bin with the hex dump of the Arb I just created with Ultrawave (361p_sine.bin). I would like to see if there is any difference between the in-between values assigned by Ultrawave and the ones assigned by the AG1012F firmware.


Attachment #2 -  This is the hex dump of 361p_sine.bin.

Notice that the value of byte 00000000 is 00. So to compare the performance of this Arb with the performance of 361p_sine_X10.bin I'm going to have to change this value to 01 using my hex editor.


Attachment #3 -  This is the hex dump of 361p_sine_X10.bin.

As expected, there are differences in the filename and filename place holders. As far as the in-between data point values, many of them are the same, but there are some with slightly different values. So it seems that the interpolation algorithm used by Ultrawave is somewhat different. What I would like to know is whether these differences will have an effect when we compare the shape and harmonic distortion of the two Arbs.

At this point I'm going to change the value of byte 00000000 in a copy of 361p_sine.bin to 01 and upload both the original and the copy to the AG1012F.


Attachment #4 -  This is the DSO image of 361p_sine_X10.bin (CH1) and the modified copy of 361p_sine.bin (CH2) when played back on the AG1012F at around 100kHz.

I can't really see any difference between the two signals at this DSO setting. I tried lower voltage settings but still couldn't see anything significant.

NOTE: I used 100kHz for these tests because the slight differences between the Arbs seemed to show up better at lower frequencies. During some preliminary tests I could hardly see any difference at 10MHz.


Attachment #5 -  This is the FFT for 361p_sine_X10.bin (CH1).


Attachment #6 -  This is the FFT for the modified 361p_sine.bin (CH2).

I think the signal purity of #5 is slightly better, but not by much in my opinion. So I would say that the interpolation algorithm used by the AG1012F firmware seems to do better, at least for sine waves.


Attachment #7 -  This is the DSO image of the modified copy of 361p_sine.bin (CH1) and the unmodified 361p_sine.bin (CH2) when played back on the AG1012F at around 100kHz.

For this screenshot I used different DSO settings to highlight the staircase shape of the unmodified Arb. At the settings used for #4 I couldn't see a noticeable difference.


Attachment #8 -  This is the FFT for the unmodified 361p_sine.bin (CH2).

I detect some deterioration of signal purity compared to #6, but not as much as I thought there would be!


                         -----------------------------------------------------


OK, time to call it quits for the Day! Quite a few other things I want to test, so .......... to be continued!

[TomC]

Ultrawave - Creating Arb Files part 2
--------------------------------------


ON this post I'd like to continue to explore Ultrawave's capabilities and performance while creating Arb files from scratch. This includes creating more complex Arbs and using some of the other drawing tools offered by Ultrawave.

On this post I'm going to use Ultrawave to create a digital Arb similar to the one featured on post 45. First, let's review the Arb created on post 45. I want to do this first because when I tried the Arb created with Ultrawave revisiting the below helped me realize what was happening.


Attachment #1 -  This is how the edit screen looked like when 11p_1101001110.bin was created.

Notice that there are only two data point voltages used, 0V and 2V. Also notice that the graph's Y scale is based on these two values since in this case they are also the max & min voltage values. Unfortunately, there are also some things that should be ignored, like the amplitude and offset values, which may seem relevant in this case, but are just leftovers from whatever operation you were performing prior to invoking waveform creation.


Attachment #2 -  This is how the screen looks like when the AG1012F is setup to output 11p_1101001110.bin at 1MHz.

In this case the amplitude and offset has to be setup correctly to obtain a waveform excursion from 0V to +2V. Since the waveform was created with 0V and 2V min & max voltage values it is a 2Vpp waveform. If there is no offset the waveform would be output with excursions from -1V to +1V, so to get excursions from 0V to +2V the offset must be set to 1V.

Alternatively, we can instead set the high and low voltage levels we want for this signal. Changing the settings to a high voltage level of 2V and a low voltage level of 0V is equivalent to setting a Vpp value of 2V and an offset value of 1V. Attachment #3 shows how the screen looks like when the high and low voltage level settings are used.


Attachment #3 -  Same as #2 but showing the high and low voltage level settings instead of the amplitude and offset voltage settings.


Attachment #4 -  This is the DSO display of #2 or #3.


Attachment #5 -  This is the hex dump of 11p_1101001110.bin. I had forgotten that I renamed this file after it was created, however, as can be seen, the name within the file is still the original filename.

Now, to create a similar file with Ultrawave I'll need to set the number of points to 17 and the voltage to 2000mV. This should set the Y scale to -2V to +2V. There isn't an option for setting the scale to unequal absolute values at its two extremes. So when you enter the value for the positive extreme Ultrawave automatically sets the negative extreme to the same absolute value.

Next I can decide between Data Line or Data Point format. Since Ultrawave always interpolates the data lines it may be less confusing to use data point format. However, the data points are very difficult to see red dots on a black background. The background color and gridline color can be changed, but I haven't found a combination that improves red dot visibility. So I'm going to use data lines since at least I can see them!

Finally, I can decide how to enter the data point voltage values. Here you can choose Hand draw, Line Draw, or Point Edit. Since Ultrawave doesn't show the cursor position, Hand Draw and Line Draw, which set the voltage based on the cursor position aren't very accurate, specially between grid lines. In contrast, Point Edit allows you to either set the voltage for a data point by clicking a spot on the screen, or by actually entering the data point number and the voltage value you want to assign to it.

I tried creating this Arb using all three choices, and it's possible, but compared to actually entering the values, I think using Hand Draw or Line Draw takes just as long or longer. For one thing, I was never able to complete the sketch without going back and redoing previous steps. Due to one reason or another every so often a click alters something you had right before and you end up going back and forth. Maybe a little practice will improve the speed, but you still don't know if the voltage settings are accurate. So unless accuracy is irrelevant, as may be the case sometimes, I find it easier to use Point Edit.


Attachment #6 -  This is how the Ultrawave screen looks like after entering all the data point voltage values. It looks the same if you use Hand Draw or Line Draw, but the voltage values may be a little off.

If Ultrawave offered a no interpolation choice for drawing the plot the diagonal connecting lines would be replaced with square angled pairs of lines. For example, the diagonal between data point 1 and 2 would become a horizontal line from 1 to the spot directly above 2 and a vertical line from there to 2, and the diagonal from 2 to 3 would become a horizontal line from 2 to the spot directly below 3 and a vertical line from there to 3. If you can imagine how the plot would look with those changes you'll know how the Arb is going to look when it's played back by the AG1012F.

I saved the file with the name 11p_dig.bin, so next I'm going to get a hex dump to compare it to #5, then I'm going to upload it and see how it looks on the AG1012F output setup screen. Finally I'm going to compare 11p_dig.bin to 11p_1101001110.bin on the DSO screen.


Attachment #7 -  This is the hex dump of 11p_dig.bin. The data point voltage values are the same as #5, however, the value of bytes 00000008 & 00000009 (considered the lowest data point value by the AG1012F) is different. I have a pretty good idea of how this is going to affect the AG1012F, but let's see what it looks like when I try to play it back.


Attachment #8 -  This is how the screen looks like when the AG1012F is setup to output 11p_dig.bin at 1MHz.

In the case of #2 I was able to set the amplitude to 2Vpp and the offset to 1V. Here, if I change the amplitude to 2Vpp the waveform will become 1Vpp, and if I change the offset to 1V the bottom of the signal will no longer be 0V. As you may have guessed, this is happening because of the values Ultrawave used for bytes 00000008 & 00000009, which the AG1012F expect to be the lowest data point value. The AG1012F thinks is dealing with a 4Vpp waveform and has scaled the screen accordingly.

As in the case of #2, we can also see the high and low voltage levels used for this waveform, this is shown on attachment #9.


Attachment #9 -  Same as #8 but showing the high and low voltage level settings instead of the amplitude and offset voltage settings.

Here again you can see that the AG1012F has been duped, the waveform's highest voltage is +2V, but the lowest voltage is 0V, not -2V.


Attachment #10 -  This is the DSO display of #2 or #3 on CH1 and #8 or #9 on CH2. As can be seen, the waveform on CH2 is identical to the waveform on CH1, and it is what I intended to create in the first place. So the only thing that is wrong is that the AG1012F thinks it's outputting a 4Vpp waveform with an offset of 0V.

Of course, this problem can be corrected by changing the value of bytes 00000008 & 00000009 to 1027 with a hex editor. It's just that I'm growing weary of the acrobatics required to make this thing work the way is supposed to!

-----------------------------------------------------------------------------------------------------------------

Below are some additional quirks that I've noticed while working on this post:


Most of the Arb files I've downloaded with Ultrawave caused the Y axis of its edit screen to default to -10V to +10V. However, with a few files I noticed a different outcome. After decoding some of these files I found out why. If the absolute value of bytes 00000004 & 00000005 (the highest data point value) is larger than the absolute value of bytes 00000008 & 00000009 (the lowest data point value), then the Y scale is set just large enough to accommodate both values. For example, if bytes 00000004 & 00000005 = 482B (1080mV) and bytes 00000008 & 00000009 = 0023 (-1040mV), then the Y scale is set to -1.08V to +1.08V.

However, let's say that you edit the above file and then save it. Since the Y scale is set to -1.08V to +1.08V, bytes 00000004 & 00000005 will be set to 482B (1080mV), which is the original value, but bytes 00000008 & 00000009 will be set to D822 (-1080mV). So what do you think is going to happen the next time you open this file with Ultrawave?


                      -----------------------------------------------------------


OK, that's it for tonight! I need a rest!

[Obin]

looks like a nice unit Might pick one up in the future

[TomC]

looks like a nice unit Might pick one up in the future

I got mine at a good price!

However, I wish  that Owon would take the time to fix some of these issues!

They haven't responded to the email I sent them over a week ago, so it's probably time to try again, maybe someone that's awake reads the email this time!

[TomC]

There were some posts where I forgot to attach copies of the Arb files discussed. So today I went through them and I believe I attached all the files that were missing.

The following are the posts I edited to attach Arb files:

39

57

59

[TomC]

Ultrawave - Creating Arb Files part 3
--------------------------------------


ON this post I'd like to continue to explore Ultrawave's capabilities and performance by editing a complex Arb file.

The issue I'd like to tackle is whether complex Arb files can be modified accurately and efficiently using Ultrawave. I've been experimenting with a file used on post 50, 63000p_v_line.bin, which originally came from my color generator.

Attachment #1 -  This is the way 63000p_v_line.bin looks like in Ultrawave's edit screen.

What I'd like to do is change the base of the sync pulse to a straight line at 516mV, and change the base of the video line to straight lines at 172 mV. I picked those voltages because since they coincide with the grid lines hopefully the task won't be as challenging.

Attachment #2 -  This is the way the waveform should look like after successfully editing it.

I've tried this different ways with different degrees of success, the attached 6300p_mod.bin is the best I've got so far. However, I think it took me too long to produce this file to call the effort both accurate and efficient. So I'm still searching for better answers. On the next post I'll give more details of what I think is the easiest way to get this done. In the mean time, I'm inviting any of you with a copy of Ultrawave that's interested to give it a try and report what you think! You don't need to own an AG1012F to get this software, it's available for download at the Owon website.


http://www.owon.com.hk/service_down.asp?SortID_1=1&SortID_2=0&seek=&curpage=3

[TomC]

Ultrawave - Creating Arb Files part 4
--------------------------------------


This post is the sequel to post 63.

Using the stock Ultrawave software, I couldn't find a satisfactory way to complete the task I proposed in an accurate and efficient way. So I decided that it was time to try to find a way to mitigate some of Ultrawave's shortcomings. There are a couple of things that slowed me down the most:

First, I found it difficult and time consuming to position the cursor on the correct spot to draw the lines at 172mV and 516mV consistently. Even with the gridlines as a guide, most of the time I would be at least a pixel off. Going to full screen improved things a bit, but still it took too many redos to get it correct!

Second, I found it very difficult to position the cursor at exactly the beginning or end of the active area of the grid. For example, when I tried to do the first click at the extreme left of the waveform, most of the time I would either be slightly to the left of the active area, where clicking does nothing, or I would be past the beginning of the active area and miss the first few pixels of the waveform.

Based on this I thought that if I could devise a way to display the cursor coordinates and reveal the grid boundaries the job would be substantially simplified. In the past I had briefly used a scripting language called Autoit for some simple tasks, so I decided to try to use it to improve Ultrawave. At this point I have a working script that satisfies these two objectives. It's still very much a work in progress since I want to see what else I can do to make it more useful. For me this is a major job because my programming experience is very limited and way back in the past. So I'm going to post both the executable and the script source in case someone with more experience wants to take a look and help improve it!


Attachment #1 -  This is the way the Ultrawave screen looks like with my script running. When you launch the script it will try to invoke Ultrawave if it's not already running. In that case it will rework the screen to appear as in this attachment. If Ultrawave is already running the small window controlled by the script will attach itself to the existing Ultrawave instance in the same position shown in this attachment.

Currently the small window reports the cursor X and Y coordinates relative to Ultrawave window's client area. It also reports the color of the pixel (hex code) at those coordinates and whether that pixel matches the default colors of the "Grid", "Window Background", or "Waveform". If the pixel doesn't match any of those colors then it reports "Other".


Attachment #2 -  This is the way the waveform I want to edit looks like after downloading it.


Attachment #3 -  Here I used the script to determine that the 172mV gridline is at Y=270.


Attachment #4 -  Here I used the script to determine that the left boundary of the grid is at X=22.


Attachment #5 -  Here I positioned the cursor at X=22, Y=270 to click the beginning of my first line at 172mV.


Attachment #6 -  Here I positioned the cursor at X=27, Y=270 to click the end of my first line at 172mV. This line was done with two clicks, no redos, just have to position the cursor carefully. Going to full screen makes that even easier.

Now I'm ready to start the next line past the first hump of color bar signal.


Attachment #7 -  This is what happens the first time I click the beginning of that second line. Ultrawave always tries to connect the current click to the previous click. If that's not what you want click "Undo", that will cause the next click to be viewed as an initial click with no connection to the previous one.


Attachment #8 -  After clicking "Undo", here I positioned the cursor at X=228, Y=270 to click the beginning of my second line at 172mV. Because I'm using Y=270, this line is at exactly the same level as the first line.


Attachment #9 -  Here I positioned the cursor at X=401, Y=270 to click the end of my second line at 172mV. To complete the edit I used the same procedure for the remaining lines. At the right end of the grid I used the script to find the right boundary in a way similar to #4.


OK, that's it for today!

I'm going to do some more work on the script to see if I can add additional functionality, for example, report actual Data Points and Voltages besides cursor coordinates. I'll post the files containing any improvements as I go along. Of course, any help or suggestions will be appreciated!

[TomC]

I just got a response from Owon regarding the phantom files, the content of their email is below:

Hello ------,
Thank you for purchasing OWON product
You are right, the filename can't exceed 14 character, we will see how to help you delete those files.
But for future, please not to make a file name more than 14 character.
Thanks,
 

--------------------------------------------------------------------------------

--------- (Mr.)
www.owon.com.hk


---------------------------------------------------------------------------------------------------------------

I've made some progress on the "Mouse Position Info" script I've been working on to enhance the functionality of Ultrawave. A version that reports "Data Points" and "Voltages in mV" in addition to mouse coordinates is almost ready. I'll probably post it later today or tomorrow.

[TomC]

Today I got a Patch utility from Owon that allows the user to erase the Internal Storage among other things. The instructions they sent me were in Chinese, but with screen shots clear enough to see what they wanted me to do.

So Happily!

The phantom files are now gone!

So if any one else managed to create some phantom files, rest assured there is a solution!

The utility is a 30MB download and may be dangerous if the user is not careful, for example, it can also erase BIOS, BOOT files, and TABLES. So if anyone needs it to erase some phantom files please contact Owon directly. If for some reason that's not an option, PM me, and I'll see if I can help!

[TomC]

Ultrawave - Mouse Position Information 1.1
--------------------------------------------


This post is the sequel to post 64.


I just finished adding a new feature to the "Mouse Position Info" script described on post 64. In addition to mouse coordinates the script now also displays the "Data Point" and "Voltage in mV" value that corresponds to the current mouse position. For this to work properly the script needs to know the current Ultrawave settings for "Number of Data Points" and "Maximum Voltage". To accomplish this I was able to get the script to automatically monitor the user activities and read the values off the "Rework" dialog whenever the user changes them. In addition the values will also be updated whenever the user either creates a new file or opens an existing file. The script will also update the values anytime the user gets done using the communications interface since this may mean that the user downloaded a file from the AG1012F.

The computation of the data point number and mV value is based on the number of pixels within the active area of the Ultrawave grid. So the script needs to monitor the Ultrawave window for any changes in width or height and automatically recalibrate the computation anytime the user changes it. This computation is extremely accurate if the number of pixels in the X axis is equal or greater than the number of data point and the number of pixels on the Y axis is equal or greater than twice the voltage setting. For other ratios a single pixel will correspond to more than one data point or voltage value. As a result, the script can only try to display the data point number or mV value that Ultrawave has assigned to that particular pixel. However, that's not always perfect, although pretty close based on my tests.

Attachment #1 -  This is the way the Ultrawave screen looks like now with the new version of my script running. Notice the cursor position and the DP and mV values displayed by the script. When Ultrawave is launched by the script the number of data points and mV scale will be initially set as shown on this image. I did this because on full screen that translates to 1 pixel per data point and 1 pixel per mV when displayed by my primary monitor which is 1920 x 1200. In the future I plan to add an option so that this default can be changed by the user.


Attachment #2 -  This is a close up of the small window controlled by the script.


Attachment #3 -  This is an Arb that I drew at full screen to test the accuracy of the values displayed by the script when we have 1 pixel per data point and 1 pixel per mV. The down slope boundaries are data point 500 at the top and data point 1500 at the bottom. The voltage values were set 1 mV apart starting at 500mV at the top and ending at -500mV at the bottom. Here the script tells us that the cursor is at data point 1337 and that the voltage value is -337mV. We also know that the cursor is resting on a red pixel because the script identifies it as having the default color used by Ultrawave for the waveforms.


Attachment #4 -  Here I'm looking at the same waveform with the AG1012F in edit mode. It shows that data point 1338 is set to -337mV. As we know, the AG1012F counts the data points starting with 1 while Ultrawave starts with 0. So this is the same data point we identified on #3.


Attachment #5 -  Here I'm looking at the color generator waveform that was modified on a previous post with Ultrawave. I picked a spot where the voltage varied quickly from one data point to the next and there were no other data points nearby with the same voltage (408mV). What I want to see is whether I can identify this same data point (3763) in Ultrawave using the script as an aid. Keep in mind that I won't have a 1 data point per pixel resolution since this waveform is 6310 data points long.


Attachment #6 -  Here I show where I found a nearby data point with the same voltage using Ultrawave and the script. This is not full screen, so the expected accuracy is not high, yet, it tells us the data point is 3760, which translates to 3761 the way the AG1012F counts data points. Not too bad in my opinion.


Attachment #7 -  Here I found it again, this time using full screen. It tells us the data point is 3763, so it's off by one, but keep in mind that the resolution is about 3.4 data points per pixel in this case (6310/1837 = 3.4).

OK, that's it for today!

[TomC]

Ultrawave - Mouse Position Information 1.2
--------------------------------------------


This post is the sequel to post 67.


I'm still working on the Mouse Position Info script and have made some improvements to the version described on post 67. The information displayed hasn't changed, but I changed the format of the small window to make it easier to read. For example, when the cursor is over a pixel that belongs to the waveform, the text "Wave", and some other window elements will be displayed in red (the same color as the waveform).

Another improvement is that the script can handle multiple instances of Ultrawave. A unique small window, with a title that includes the handle of the associated Ultrawave window, is paired with each Ultrawave instance. The original version of the script was limited to a single instance.

I've also added a context menu that can be accessed by right clicking the small window's title bar. However, most of the options/features are still a wish list. At this point, most of them will just display a message indicating that they are not implemented yet if you click them.

One final improvement is that the free standing executable is now highly compressed and about half the size of the original version. This contains all the necessary AutoIt code to run on a Windows PC that doesn't have AutoIt installed. The .au3 file is a text file with the script's source code that can be viewed with notepad, however, to run this file AutoIt 3 must be installed in the PC.

----------------------------- WARNING! ---------------------------
Anyone that decides to try these program files, please realize that you do so at your own risk! I've tried these files on three different Win7 computers without any ill effects, but I can't guarantee that your experience will be the same!


Attachment #1 -  This illustrates multiple instances of Ultrawave each paired to a small Mouse Position Information 1.2 window.


Attachment #2 -  This is a close up of the small Mouse Position Information 1.2 window. It illustrates how the window looks when the cursor is over a pixel that belongs to the waveform.


Attachment #3 -  This illustrates the context menu and one of its submenus. These are some of the options/features that I'm currently planning to implement in the future.

[TomC]

Ultrawave - Mouse Position Information 2.0
--------------------------------------------



The Mouse Position Info script has gone through several iterations since my last post. The context menu I mentioned on post 68 has been revised several times and all the options/features with the exception of "Convert to .ota" are now implemented. At this point I think I've gotten around all the UW quirks that I could possibly automate using a script. For example, the max and min mV values are now saved the way the AG1012F expects them. So waveforms edited with UW will play back the same way as when edited with the AG1012F UI. Also, when a new file is created interpolation is set to "ON". So the files created with UW, which always renders waveforms using interpolation, will look and be rendered the same way on the AG1012F.

To accomplish this, when the script is running it disables the UW file menu and related toolbar buttons to make sure that the user performs these operations using the context menu. All of the UW native functions are still available via the context menu, but they are under the control of the script, which takes additional actions to get around some of the UW quirks. This allows the script to keep track of the file that is being edited and gives it the opportunity to make any changes that UW doesn't do correctly before saving it.

Some other improvements include displaying the filename on the title bar of the UW window as well as the script windows. When using vanilla UW I often would forget which file I was editing and not having the filename on the title bar, as most windows applications do, was quite annoying. Another improvement is making the file named during a "Save As" the current file, as most windows applications do. Vanilla UW doesn't behave this way and since it doesn't even display the name of the current file the user can easily end up overwriting the original file accidentally.

This version of the script also adds a File Information window. This includes the values of the key file fields, the full path of the file, and the modified time stamp. So the user can see whether interpolation is ON or OFF and can see the file's internal name. Options in the context menu allow the user to modify either one of these fields.



----------------------------- WARNING! ---------------------------
Anyone that decides to try these program files, please realize that you do so at your own risk! I've tried these files on three different Win7 computers without any ill effects, but I can't guarantee that your experience will be the same!


Attachment #1 -  This illustrates all the windows associated to a particular file.


Attachment #2 -  This is a close up of the File Information window.


Attachment #3 -  This illustrates the Main context menu and the File submenu. The only option that isn't implemented is "Convert to .ota". Don't know when I'll tackle that, first I'll have to see if I can decode an .ota file. The reason I would like to do this is because .ota files include frequency and voltage settings. So it would be nice to just play a file and have it set itself up automatically.

Attachment #4 -  This illustrates the Rework submenu. The "1 DP/px and 1mV/px" item allows the user to automatically set the UW Grid to the number of Data points and maximum mV values that correspond to 1 pixel per unit for the current window size. The other item, "Voltage to Max Zoom", looks through all the waveforms data points and finds the highest absolute voltage value, then sets the UW Grid to that value so the waveform is enlarged to the maximum possible.

[eosintickleear]

N-Cycle Burst Part 1
------------------

On this post I'd like to explore the N-Cycle Burst.

First, let's review the Owon specs and some of Owon's instructions, definitions, & notes verbatim from the manual:


Burst (specs)
---------------------------------------------------------------------------
Waveforms          Sine, Square, Ramp, Pulse, Arbitrary
Types             Count (1 to 1,000,000 periods), infinite, gated
Start Phase          -360° - +360°
Internal Period       (10 ms - 500 s) ± 1%
Gated Source          External Trigger
Trigger Sources       Source, External or Manual

Note: I believe some of the above lines contain errors and should read:

Types             Count (1 to 50,000 periods), infinite, gated
Trigger Source         Internal, External or Manual


External Trigger Input (specs)
---------------------------------------------------------------------------
Level             TTL-compatible
Slope             Rising or falling (selectable)
Pulse Width          >100 ns
Trigger Delay          0.0 ns - 60 s

Note: I haven't found a way to change the Slope or the Trigger Delay. When I tried the external trigger for N-Cycle Burst the sweep starts when the Slope is falling.

Some of the instructions & notes from the manual
---------------------------------------------------------------------------

To Generate Burst

Burst function is only used for CH1. Burst can last for certain times of waveform cycle (N-Cycle Burst), or to be controlled by external gated signals (Gated Burst). Burst can apply to Sine, Square, Ramp, Pulse and Arbitrary waveforms (Noise can not be used).

Set N-Cycle Burst

Start Phase (if current waveform is Pulse, skip this step), define the Start and the Stop Point in a waveform. The phase varies from -360° to +360°. For an Arbitrary Waveform, 0° is the first waveform point.

Set the number of Waveform Cycle in an N-Cycle (from 1 to 50,000). If you choose Infinite, then a continuous waveform will be generated which will not stop until a trigger event happens (the knob on the front panel is pressed).

Note:
- If needed, Burst Period will increase to cater to the specific number of cycles.
- For an infinite-cycle Burst, External or Manual Trigger is needed to activate burst.


Internal means using the internal source. External means using the Ext Trig/Burst/Fsk In connector in the rear panel to input the external signal. Manual means choosing manual trigger; in N-Cycle Burst interface, press the knob on the front panel to output a burst signal.

Term Explanation
----------------------------------------------------------------------------

Burst:
Output Waveforms with set cycle times. Generally it is called BURST function within every Signal Generator.

N-Cycle Burst:
N-Cycle has specific number of waveform cycles, and every burst is activated by a trigger event.

Gated Burst:
Gated burst use external source to control burst as when to be activated.


             ------------------------------------------------------------------------

With the above in mind I'd like to start with some examples using the internal trigger. The basic settings and connections are the same as used in previous posts. Other settings can be read from the AG1012F & SDS7102 images.


Attachment #0 - This is the AG1012F Manual's figure that explains how to read the display during N-Cycle burst.


Attachment #1 - This shows the basic N-Cycle Burst setup I'm using for the next 5 images. The only difference is that each image will use a different signal shape. Notice that for these examples I set the Start phase to 180°. What I want to see is whether the AG1012F correctly picks the starting point that corresponds to 180° for each signal shape. The DSO is triggered on CH1 using an appropriate slope and holdoff to trigger on the first cycle of the burst.

#1 - This is the SDS7102 image while viewing #1 with the shape set to sine. Here there is no doubt that the phase is correct.

#2 - This is the SDS7102 image while viewing #1 with the shape set to square. Although I have the Duty cycle set to 20%, as was the case for sweep, the AG1012F doesn't change the output waveform and always uses 50% duty cycle. So considering that the duty cycle is 50%, 180° happens at the same instant as the positive to negative transition. Since Owon picked the negative end for 0°, it seems reasonable to pick the positive end for 180°.

#3 - This is the SDS7102 image while viewing #1 with the shape set to ramp. Here I have the ramp set to 100% Symmetry. Just like in the case of the square wave, it seems reasonable to pick the positive end for 180°.

#4 - This is the SDS7102 image while viewing #1 with the shape set to pulse. Although this signal shape is closely related to square, in this case the AG1012F does change the output waveform to match the duty cycle or pulse width setting. In this case I have the duty cycle set to 25%. So 180° happens sometime after the positive to negative transition.

#5 - This is the SDS7102 image while viewing #1 with the shape set to ARB. For the ARB I'm using the Besselj built-in arb from page 2 of Maths. This waveform has 3 cycles, the first cycle has the highest amplitude and the third one the lowest. The AG1012F says that 180° is just after the 180° mark of the second cycle. Although in a perfect world the waveform should have started at the 180° mark of the first cycle, the AG1012F is assuming that the waveform is just one cycle. So in my opinion, this isn't a malfunction, it is however a limitation that the user needs to keep in mind.


I'm not done with burst yet, so .... to be continued!

Thank you TomC it's very good and precise information.
You are so kindnees.
Will learning from this. Thanks again.

Eosintic

[TomC]

Thanks Eosintic,

Glad you find it useful!

[PM Smith]

Hello TomC,
thanks for your extensive review. I have therefore bought this generator.
I was also unhappy with the creation of arb-files.
I wrote a small vba-excel script to create and write the .bin files.
It is certainly not yet perfect but maybe someone find it useful.

PM Smith

[TomC]

Hi PM Smith,

Thanks for the contribution! I haven't had a chance to try your script because I don't have Excel, but I see there have been some downloads so other members or guests may already be using it.

Hopefully someone will provide some feedback! I'd like to encourage members, or guests that may want to register, to provide feedback after trying scripts/software provided in this forum. It can be very helpful for the writers and provide insight for further improvement!