...but mine do not have PT1000 (I do not know if it is a old sw version or if unsupported on 3045).
As far as I know the operation of PT1000 in the 3045X is not mentioned in the documentation,
nor as a new function in the firmware history.
The speed setting works fine on 3045, but mine do not have PT1000 (I do not know if it is a old sw version or if unsupported on 3045).
HKJ,
I just checked the SDM3045X Firmware History and it does not show add PT1000 support. You can try updating the firmware to see if was just undocumented. If you fine that the current firmware still does not support PT1000 I will update the device file.
Firmware link
https://www.siglenteu.com/service-and-support/firmware-software/digital-multimeters/
I just checked the SDM3045X Firmware History and it does not show add PT1000 support. You can try updating the firmware to see if was just undocumented. If you fine that the current firmware still does not support PT1000 I will update the device file.
I am running that firmware version.
I just checked the SDM3045X Firmware History and it does not show add PT1000 support. You can try updating the firmware to see if was just undocumented. If you fine that the current firmware still does not support PT1000 I will update the device file.
I am running that firmware version.
HKJ,
File updated
SiglentSDM30xxx.txt (16.99 kB - downloaded 45 times.)
File updated
I have updated and PT1000 is gone.
Managed to do rms (dB), frequency and phase* with my HMO 1022 scope
However, there seems to be a division-by-zero error when the phase goes to/through Zero. This error does not come from the scope as it displays small phase angles correctly when queried.
The pic shows what happens when switching off the signal even briefly (switching transient when changing the frequency, for example). Phase and frequency do not recover. RMS does.
This applies to Chart only. Table and Current values are OK.
More info: Its only the automatic scale ranging which is upset. Setting the phase range manually is OK.
*Phase logging is important when aligning tape heads for Zero phase between channels.
Managed to do rms (dB), frequency and phase* with my HMO 1022 scope
However, there seems to be a division-by-zero error when the phase goes to/through Zero. This error does not come from the scope as it displays small phase angles correctly when queried.
Can you save a CSV file with the problematic data and send to me, then I will look at it.
The values may be correct, I will see that in the CSV file, but there are definitely way to many zeros, it has to switch number format.
Managed to do rms (dB), frequency and phase* with my HMO 1022 scope
However, there seems to be a division-by-zero error when the phase goes to/through Zero. This error does not come from the scope as it displays small phase angles correctly when queried.
Can you save a CSV file with the problematic data and send to me, then I will look at it.
The values may be correct, I will see that in the CSV file, but there are definitely way to many zeros, it has to switch number format.
HKJ,
I see something similar when using the /factor 330 /100 should equal 3.3 not 3.3000000000000003. The data is saved correctly in the csv file. Also in the csv file when using Excel to convert the dateTime column to a true date format it cannot.
test data.csv.txt (0.34 kB - downloaded 43 times.)
;; RD6006: Tx <values?>
;; RD6006: Tx <holding? 0x08 /100;holding? 0x09 /1000;holding? 0x0A /100;holding? 0x0B /1000;holding? 0x0D /100;holding? 0x21 /100;holding? 0x23;holdingl? 0x26 /1000;holding? 0x28 /1000>
;; COM3: Tx: 01 03 00 08 00 01 05 C8
;; COM3: Rx: 01 03 02 01 4A 38 23
;; COM3: Tx: 01 03 00 09 00 01 54 08
;; COM3: Rx: 01 03 02 01 F4 B8 53
;; COM3: Tx: 01 03 00 0A 00 01 A4 08
;; COM3: Rx: 01 03 02 01 4A 38 23
;; COM3: Tx: 01 03 00 0B 00 01 F5 C8
;; COM3: Rx: 01 03 02 01 47 F9 E6
;; COM3: Tx: 01 03 00 0D 00 01 15 C9
;; COM3: Rx: 01 03 02 00 6B F9 AB
;; COM3: Tx: 01 03 00 21 00 01 D4 00
;; COM3: Rx: 01 03 02 00 07 F9 86
;; COM3: Tx: 01 03 00 23 00 01 75 C0
;; COM3: Rx: 01 03 02 00 1C B9 8D
;; COM3: Tx: 01 03 00 26 00 02 25 C0
;; COM3: Rx: 01 03 04 00 00 00 93 BA 5E
;; COM3: Tx: 01 03 00 28 00 01 04 02
;; COM3: Rx: 01 03 02 00 00 B8 44
;; RD6006: Rx <3.3000000000000003 0.5 3.3000000000000003 0.327 1.07 0.07 28 0.147 0.0>
;; RD6006: Rx as numbers <3.3000000000000003 0.5 3.3000000000000003 0.327 1.07 0.07 28.0 0.147 0.0>
I see something similar when using the /factor 330 /100 should equal 3.3 not 3.3000000000000003. The data is saved correctly in the csv file. Also in the csv file when using Excel to convert the dateTime column to a true date format it cannot.
Floating point precision is always limited on a computer. Internally I uses the double format with 64 bits precision, but if you include enough digits you will often see an error.
Messtechniker may have two problems, one is that I do not switch to scientific notation, but shows all the digits, the other is the large value.
Please find enclosed a .csv file (rename .txt. to .csv) where at first I am logging along nicely followed by switching the signal source off and then on again. See corresponding Screenshots 1 and 2.
Here is an updated file for the SDG 1062X waveform generator. This adds the functions mentioned in my earlier post, plus a new one -- the ability to specify the expected load impedance.
That allows one to set accurate levels at loads other than just 50 ohms and High-Z. So, for instance, one could specify 600 ohms if used in an audio environment, or 75 ohms for certain RF work, etc., and the instrument would then adjust its internal calibration so that the requested output level was indeed presented to the load.
HKJ :
(1) I did not look at the #meta tags so this needs some work to merge with the 2122 parent; sorry.
(2) For some reason the letter "K" is not rendering in the upper limit for the load Z variable. See the attached pic, where the text "50 - 100K" shows up as "50 - []". Is this an encoding issue, perhaps?
Please find enclosed a .csv file (rename .txt. to .csv) where at first I am logging along nicely followed by switching the signal source off and then on again. See corresponding Screenshots 1 and 2.
And the CSV file is mostly useless because I did not save the very high values correctly (A Java issue). I have worked a bit on it in a update, you can try this jar file:
httpp://lygte-info.dk/pic/Projects/TestController/TestController.jar
Here is an updated file for the SDG 1062X waveform generator. This adds the functions mentioned in my earlier post, plus a new one -- the ability to specify the expected load impedance.
I will take a look at it tomorrow. The problem with the K is probably because 100K is a invalid number, it has to be 100k
Managed to do rms (dB), frequency and phase* with my HMO 1022 scope
Did you do you own dB calculations or did you use the build in dB functions?
dBV(voltage): Calculate relative to 1V
dBm(power): Calculate relative to 1mW
dBm(voltage, impedance): Calculate relative to 1mW
Hexley, I'm testing your SDG1062X definition.
Just started but it looks good so far.
How difficult is it to include V rms there ?
dB calculation is relative to 0,775 mV = 0 dBu using the math of Test Controller.
like such: log((HMO1022.RMS/0.775)*(HMO1022.RMS/0.775))*10
Low dB values (below 0.0775 mV) bottom out at -20 dB. This is due to the scope.Must stop now - getting too tired.
dB calculation is relative to 0,775 mV = 0 dBu using the math of Test Controller.
like such: log((HMO1022.RMS/0.775)*(HMO1022.RMS/0.775))*10
Low dB values (below 0.0775 mV) bottom out at -20 dB. This is due to the scope.
I do not have a dBu version, but I do have a sqr function (and a sqrt function). I believe that dBm(value,600) is the same as dBu
How difficult is it to include V rms there ?
To specify the output level in RMS Volts rather than peak-to-peak volts would require math operations that depend on the waveshape.
For waves with a 50% "duty cycle", like sine or square or tirangle waves, the conversion factors between Vpp and Vrms are well known constants and easy to apply. But for non-symmetric waves like pulse or sawtooth, things get messy, as you have to account for duty cycle which is of course a variable quantity. And for some waves, like ARB, there is no way around doing a point-wise calculation to get the root of the mean squared-values in order to get an accurate RMS number.
So I guess the answer is that a general solution is "quite difficult", so we will have to do the rms conversion manually in cases where we can, like sine waves. No doubt that is one reason HKJ included the pop-up calculator.
To specify the output level in RMS Volts rather than peak-to-peak volts would require math operations that depend on the waveshape.
Correct and they are build into the generator for some waveforms, due to the "some" (and a bit of laziness) I decided not to include it. But if you decide to include it it would be nice
The calculator is because I like that style of calculator and the one I wrote before (
http://miscel.dk/MiscEl/miscel.html ) is a bit dated (Last update is more than 8 years ago). The typical calculator with buttons for each digit and function is silly in my opinion (Except if you are using a touch screen).
Correct and they are build into the generator for some waveforms,
Well, well. Turns out the SDG programming reference has been revised along the way -- the original one did not mention Vrms (nor DBM, for that matter).
I have downloaded the revised version, and will take another look at Vrms...
[Edit: Here is a version that supports Vrms and dBm input for setting the amplitude.]
With my old generators there was only V pp, so of course I couldn't avoid calculating,
with the SDG I found it very convenient (ok, maybe I got lazy) to be able to enter rms directly.
Thank you very much for V rms.
And the CSV file is mostly useless because I did not save the very high values correctly (A Java issue). I have worked a bit on it in a update, you can try this jar file: http://lygte-info.dk/pic/Projects/TestController/TestController.jar
Much better now with the above TestController.jar.
See pic and Test.txt resp. Test.csv.
Also cleaned up my quick-and-dirty dBu (i.e. dB unloaded) calculation:
It now runs: log(sqr(HMO1022.RMS/0.775))*10
(Initially I did not use the sqr operator because of a bad experience with it in connection with another program
).
Anyway I'm getting quite a lot of fun out of this.
Also cleaned up my quick-and-dirty dBu (i.e. dB unloaded) calculation:
It now runs: log(sqr(HMO1022.RMS/0.775))*10
You could also have used: dBm(HMO1022.RMS,600)
Have you found out how to control the sequence of the scales?
The first one checked goes to the left, next one is first to the right, then second to the right. I.e. remove all checkmarks, then check them in the sequence you want the scales.
V0.55 is up
The updated Siglent SDG is included, I added 1000X, 2000X & 6000X series. I change the impedance setting to a combobox, because I want a possibility to return to HiZ (This is not the ideal solution).
I have added help to the Math page. There is now a list of support functions and description of Math types. I anybody has ideas to useful function or types, please post.
Large values is handle better now. It will switch to scientific notation when value is too high for the format. Very close to zero values will be shown as 0.