Few days ago, I received my UTG962E ...
Here are the results of my first investigations
1) could confirm the video-loop from IAmBack (Replay #236 June 25, 12:50 pm)
- second reference was my old MHS5200A (26bit DDS-core claim 200MHz, but running at 176MHz)
- next step was a frequency measurement over time (10s gate time)
-> observed instable results
-> did time sequence for UTG962 and MHS5200A picture: 20MHz_frequency_drift_comparison
what can we see
- frequency counter is good enough
- MHS5200A is showing smooth frequency drift during heating up
- UTG962 WTF ...
====snip====
There was some guy that did a full break down of 4 models UTG962 the Rigol ,Siglent , and I forgot the other .
I will try and find the link he did a really good comparison very long from what I recall 20 pages on a PDF.
and compared the UTG against some of the way more expensive and from I recall the UTG came very close
to second place . I will search for the document I am sure I downloaded it . it was last year so I have thousands
of PDFs to search .
There was some guy that did a full break down of 4 models UTG962 the Rigol ,Siglent , and I forgot the other .
I will try and find the link he did a really good comparison very long from what I recall 20 pages on a PDF.
and compared the UTG against some of the way more expensive and from I recall the UTG came very close
to second place . I will search for the document I am sure I downloaded it . it was last year so I have thousands
of PDFs to search .
Perhaps it was these blog posts on element14:
https://www.element14.com/community/groups/roadtest/blog/2020/05/17/tektronix-afg31052-verification-tests
https://www.element14.com/community/groups/roadtest/blog/2020/05/17/tektronix-afg31052-verification-tests-part-2
I received my UTG932E yesterday. I am impressed by the build quality for the price !
The CPU is a Gigadevice GD32F207ZCT6 (crazy what you can do with isopropanol and a good view angle).
The firmware is not protected... I could not resist ...
After dumping the code I was able to extract the SCPI commands that are recognized by the device. That could come handy when trying to remote control the device.
Some of them still need to be identified.
The commands are:Code: [Select]*IDN
*RST
CHANnel<n>:AMPLitude:UNIT
CHANnel<n>:ARB:INDex
CHANnel<n>:ARB:SOURce
CHANnel<n>:BASE:AMPLitude
CHANnel<n>:BASE:DUTY
CHANnel<n>:BASE:FREQuency
CHANnel<n>:BASE:HIGH
CHANnel<n>:BASE:LOW
CHANnel<n>:BASE:OFFSet
CHANnel<n>:BASE:PERiod
CHANnel<n>:BASE:PHASe
CHANnel<n>:BASE:WAVe
CHANnel<n>:FM:FREQuency:DEV
CHANnel<n>:FSK:HOPPing:FREQuency
CHANnel<n>:INVersion
CHANnel<n>:LIMit:ENABle
CHANnel<n>:LIMit:LOWer
CHANnel<n>:LIMit:UPPer
CHANnel<n>:LOAD
CHANnel<n>:MODe
CHANnel<n>:MODulate:ARB:INDex
CHANnel<n>:MODulate:ARB:SOURce
CHANnel<n>:MODulate:DEPTh
CHANnel<n>:MODulate:FREQuency
CHANnel<n>:MODulate:SOURce
CHANnel<n>:MODulate:WAVe
CHANnel<n>:OUTPut
CHANnel<n>:OUTPut:SYNC
CHANnel<n>:PM:PHASe:DEV
CHANnel<n>:PULSe:FALL
CHANnel<n>:PULSe:RISe
CHANnel<n>:SWEep:FREQuency:STARt
CHANnel<n>:SWEep:FREQuency:STOP
CHANnel<n>:SWEep:TIMe
CRC
CVER
DISPlay
DISPlay:Data
IDN
KEY:<k>
KEY:<k>:LED
RP<n>:ADDR<a>
SCPI
SYNC<n>:CMD<a>
SYSTem:BEEP
SYSTem:BRIGhtness
SYSTem:CONFigure
SYSTem:CYMometer
SYSTem:CYMometer:DUTY
SYSTem:CYMometer:FREQuency
SYSTem:CYMometer:PERiod
SYSTem:ERR
SYSTem:INFo
SYSTem:LANGuage
SYSTem:LOCK
SYSTem:NUMBer:FORMat
SYSTem:PHASe:MODe
SYSTem:SLEEP:TIMe
UPDate
WARB<n>:CARRier
WARB<n>:MODulate
WFILE
WP<n>:ADDR<a>
You will find more details in the pdf attached to this post.
I also monitored the traffic between the CPU and the 24LC64 eeprom and dumped the eeprom. Interesting as my UTG932E turned now to be a UTG962E.
The 496 first bytes of the eeprom are used to store the current configuration. The model definition is store at the end of the eeprom (see print screen). I did not find the serial number in it.
As the model type (30 or 60Mhz) is stored in the eeprom and the eeprom is only connected to the CPU, there might be a possibility that a SCPI command could change the model. I modified it the hard way with my TL866 programmer but this would of course be more convenient via SCPI.
Enjoy!
Edit: Reduced pictures size
Hello, I have a few questions, I hope to get an answer.
When you fine tune the frequency output by turning the knob on the UTG662, do the output waveform glitches ?
Occurs there glitches at all ?
Thanks in advance.
I have attached a PDF document ProgrammingGuide_UTG900E.
To ptluis
Thanks for reply.
How did you get the UTG932 converted to UTG962 ? Is it easy.
Also Amazon had a 10Ah USB battery pack on sale, so I decided to have a go at making my UTG portable.
Works great - I'll have to do some noise measurements to see if the cheap regulator inside the battery pack is making any noise.Can you provide a link for that battery pack? Looks really cool solution!
Also, where did you get the USB to barrel cable from?
Battery pack: https://www.amazon.com/gp/product/B07QXV6N1B/
Right-angle cable: https://www.amazon.com/gp/product/B075112RM6/
Anker typically makes good stuff so I'm fairly confident it's a quality pack. The cable I just found by searching "right angle usb to 5.5 2.1"
Found a bug!
My version is: SW 1.09, HW 1.01, FPGA 1.07
Problem is the "start frequency" for the sweep mode.
In both modes ("line" and "log") the entered value for "start frequency" is always ignored. HW starts at 0Hz!
I am not impressed. The generator is utterly useless.
My 2 FY6900's are light years cleaner that this piece of junk.
The trash that this thing produces is off the scale.
I use the FY6900 to align vintage radios and it is fairly clean.
This thing when just the ground is attached to chassis ground causes the DUT radio to receive trash. Hooking the thing up to the antenna or other points obliterated the fundamental generated frequency. Now...how do I get a refund?
The firmware is not protected... I could not resist ...
......
...
"I also monitored the traffic between the CPU and the 24LC64 eeprom and dumped the eeprom. Interesting as my UTG932E turned now to be a UTG962E. "
The 496 first bytes of the eeprom are used to store the current configuration. The model definition is store at the end of the eeprom (see print screen). I did not find the serial number in it.
#include <Wire.h>
#define ADDR_Ax 0b001 //A2, A1, A0
#define ADDR (0b1010 << 3) + ADDR_Ax
void setup() {
Serial.begin(115200);
Wire.begin();
}
#define line_length 16
#define rows 32
void loop() {
//Serial.print((char)readEEPROM(0x1F0B));
//writeEEPROM(0x1F0B, 0x36); //make 60MHz
//writeEEPROM(0x1F0B, 0x33); //make 30MHz
//Serial.print((char)readEEPROM(0x1F0B));
dump(0x1EA0);
while(1);
}
void dump(int base_addr){
for (long i=0;i<(rows*line_length);i+=line_length){
Serial.print(i+base_addr, HEX);
Serial.print(":\t");
for (long j=0;j<line_length;j++){
Serial.print(readEEPROM(j+base_addr+i),HEX);
Serial.print(" ");
}
Serial.print("\t");
for (long j=0;j<line_length;j++){
Serial.print((char)readEEPROM(j+base_addr+i));
Serial.print(" ");
}
Serial.println();
}
}
void writeEEPROM( int eeaddress, uint8_t data )
{
Wire.beginTransmission(ADDR);
Wire.write((eeaddress >> 8)); // MSB
Wire.write((eeaddress & 0xFF)); // LSB
Wire.write(data);
Wire.endTransmission();
delay(5);
}
byte readEEPROM( unsigned int eeaddress )
{
byte rdata = 0xFF;
Wire.beginTransmission(ADDR);
Wire.write((eeaddress >> 8)); // MSB
Wire.write((eeaddress & 0xFF)); // LSB
Wire.endTransmission();
Wire.requestFrom(ADDR, 1);
if (Wire.available())
{
rdata = Wire.read();
}
return rdata;
}
Notes:The returned model number should be consistent with the nameplate information.