UNI-T UTG932/UTG962 200MSa/s Function Arbitrary Waveform Generator

[valcher]

I would like to clarify what the FPGA firmware is responsible for, the control interface?

[Yuriy V.]

Синтезатор (synthesizer)

[onx]

This firmware UTG900E.bin doesn't have SRC check
We can change FW version to any we want.
Now my 3.06 changed to 1.09

[Aldo22]

normal or not ?? Is my copy bad?

I don't know enough about it and I don't have such a device, but why don't you compare the information in the data sheet with your measurements?
Like "phase noise" and "shake": https://www.batronix.com/files/Uni-Trend/UTG900E/UTG900Edatasheet.pdf

[Aldo22]

Hi,

because there is no value for shake at sine waves. And because I don't understand what a value of -125dBc/Hz means at phase noise.

I understand that you would prefer it if someone with an UTG932 could confirm your measurements.
I can't, but I think that some jitter is normal. It's still a cheap FG.

If you want to know more about it theoretically:
German: https://de.wikipedia.org/wiki/Phasenrauschen#Messung

Lots of background (English)
https://www.npl.co.uk/special-pages/guides/gpg68_noise

Maybe you could ask the question more generally in another subforum. Maybe "Metrology" or "Beginners", I don't know.
There are already such topics: https://www.eevblog.com/forum/metrology/phase-noise-measurement/msg3337416/#msg3337416

[valcher]

I seem to have found what the write error problem is, the new UTG900 has w25q64 memory, and the old w25q80 memory. And also, there is a slight difference - see the photo.
Now I can't confirm my guess yet, because there is no such memory, but I ordered it and am waiting for it.

[Yuriy V.]

And also, there is a slight difference - see the photo.

Are the FPGA chips used in them completely identical?

[valcher]

All chips are identical, only the FPGA itself is from different manufacturers.
My guess was not crowned with success, I tried to flash a new flash with a programmer, but it did not bring any effect. Moreover, I accidentally rewrote the native flash image and now I can’t revive the generator. If anyone can share the image.

[valcher]

I found the original firmware and restored everything.

[Yuriy V.]

I found the original firmware and restored everything.

Version?

[valcher]

Version?

FPGA - 1.07

[Yuriy V.]

Anybody has Software (firmware) version 1.09 BIN file?

[Evgeni62]

Does anyone have firmware with Russian language?

[valcher]

@Evgeni62
It seems like this never happened.
@Yuriy V.
What is the difference between 1.09 and 1.07?

[Yuriy V.]

What is the difference between 1.09 and 1.07?

Scroll above, I posted a screenshot - and you will understand what I’m talking about.

[Yuriy V.]

Inrush Current when power switch moves to ON.

[PatrickB]

Hi Onx,
Can you send me the link to download firmware version 1.09.
Thanks

[renaatd]

After struggling with the UNI-T Device Manager, I decided to try do ARB uploads directly from CSV/text file with a Python script.
The SCPI/VISA interface has several quirks, so it took longer than expected to have the details right. It now seems to work, and might be useful for others, so here it is:
https://github.com/renaatd/utg962

[Eltax1693]

EDIT: I found it.

Maybe a stupid question. Where do I update firmware? UTG962E.

Thank you.

[Yuriy V.]

I have already reported above about the problem with spontaneous channel shutdowns, etc., with a simultaneous increase in the consumed current to almost 2 A and stronger heating of the generator during its operation. The reason for all this was the inrush current when turning on the generator, reaching 5-6 A (see my post above). In addition, the power switch is rated for a maximum of 3 A. As a result, over time, carbon deposits formed on the switch contacts and their resistance increased. Which led to a loss of voltage, and after some time, to a malfunction (strange behavior) of the DC-DC converter. I think that the best way to combat this phenomenon is to short-circuit the power switch terminals. Yes, this adds inconvenience, but eliminates the problem.

[aix]

I've been trying to get pyvisa going with my UTG962E.  It's mostly working, except for grabbing a screenshot with Display:Data?.  The scripit hangs when trying to read the bitmap.

I'd love some help troubleshooting this.  This is on Ubuntu 24.04, python 3.12.3, pyvisa 1.14.1 with the pyvisa_py backend (0.7.2).

Here's the code:

import pyvisa
pyvisa.log_to_screen()
ADDR = "USB0::26198::2100::AWG1523500244::0::INSTR"
rm = pyvisa.ResourceManager()
sgen = rm.open_resource(ADDR)
sgen.write("*IDN?")
print(sgen.read())
sgen.write("Display:Data?")
disp = sgen.read_raw()[15:]  # <<< HANGS HERE

There's nothing especially interesting in the pyvisa logs:

2024-10-03 12:50:28,848 - pyvisa - DEBUG - No visa library specified, trying to find alternatives.
2024-10-03 12:50:28,848 - pyvisa - DEBUG - Environment variable PYVISA_LIBRARY is unset.
2024-10-03 12:50:28,869 - pyvisa - DEBUG - Not loading dll_extra_paths because we are not on Windows or Python < 3.8
2024-10-03 12:50:29,440 - pyvisa - DEBUG - Automatically found library files: [None, None, None, None, None]
2024-10-03 12:50:29,441 - pyvisa - DEBUG - No user defined library files
2024-10-03 12:50:29,441 - pyvisa - DEBUG - Did not find IVI binary
2024-10-03 12:50:29,453 - pyvisa - DEBUG - SerialSession was not imported No module named 'serial'.
2024-10-03 12:50:29,522 - pyvisa - DEBUG - USBSession and USBRawSession were correctly imported.
2024-10-03 12:50:29,538 - pyvisa - DEBUG - TCPIPSession was correctly imported.
2024-10-03 12:50:29,541 - pyvisa - DEBUG - GPIBSession was not imported No module named 'gpib'.
2024-10-03 12:50:29,541 - pyvisa - DEBUG - pyvisa-py is available.
2024-10-03 12:50:29,541 - pyvisa - DEBUG - Created library wrapper for py
2024-10-03 12:50:29,542 - pyvisa - DEBUG - Created ResourceManager with session 8035761
2024-10-03 12:36:55,882 - pyvisa - DEBUG - USB0::26198::2100::AWG1523500244::0::INSTR - opening ...
2024-10-03 12:36:55,906 - pyvisa - DEBUG - USB0::26198::2100::AWG1523500244::0::INSTR - is open with session 8719109
2024-10-03 12:36:55,908 - pyvisa - DEBUG - USB0::26198::2100::AWG1523500244::0::INSTR - reading 20480 bytes (last status <StatusCode.success_max_count_read: 1073676294>)
UNI-T Technologies,UTG900E,AWG1523500244,3.06
2024-10-03 12:36:55,911 - pyvisa - DEBUG - USB0::26198::2100::AWG1523500244::0::INSTR - reading 20480 bytes (last status <StatusCode.success_max_count_read: 1073676294>)

Given that some of you got this working earlier in the thread, I'd love to understand the diff between your environment and mine.

Edit 1: forgot to mention that this is on aarch64 (Raspberry Pi).

Edit 2: I've been playing with other SCPI commands.  It appears that some commands consistently work while other consistently fail, and this seems to correlate with the length of the response.  I wonder if exceeding the USB device's wMaxPacketSize (64 bytes) might be what's triggering the issue.  Or something along those lines.  Thoughts?

Edit 3: I saw this commit from two days, but it didn't help.  I also added a bunch of logging throughout the stack, which suggested it's not a packet reconstruction isssue: for a broken command, the very first read from the libusb1 endpoint seems to block forever.

[eTobey]

Try adding 100ms delay before and after "sgen.write("Display:Data?")"

[aix]

Try adding 100ms delay before and after "sgen.write("Display:Data?")"

Thanks for the suggestion.  I tried it, but it didn't fix the issue.

One interesting observation is that I saw SYSTem:INFo? work, but only just once.  It's one of those commands that I couldn't get to work before, I suspect because of its long output (70 chars).  When I saw it work, I re-ran the exact same script a bunch of times but it was back to locking up on read().

All of this does seem to hint at a timing issue of some sort.

Would love to hear other ideas or suggestions.

[eTobey]

Try adding 500ms.

Try sockets like i do here:
https://www.eevblog.com/forum/testgear/scpi-virtual-feature-fixed-measurement-gates-siglent-sds800x-hd-and-the-like/msg5660515/#msg5660515

[aix]

I tried various timings, but to no avail.

The device doesn't have Ethernet, only USB.  (In fact, I plan to make a USB-to-Ethernet bridge but for that I obviously need to get USB comms working.)