Author Topic: The Siglent SDG2042X Thread  (Read 254897 times)

0 Members and 2 Guests are viewing this topic.

Offline chipss

  • Contributor
  • Posts: 38
  • Country: us
Re: The Siglent SDG2042X Thread
« Reply #875 on: March 01, 2018, 02:08:47 am »
About to find out, have one on order.
 
The following users thanked this post: seronday

Offline Qw3rtzuiop

  • Regular Contributor
  • *
  • Posts: 60
  • Country: de
Re: The Siglent SDG2042X Thread
« Reply #876 on: March 01, 2018, 02:16:52 am »
Do a firmware downgrade to and follow the instructions:
https://www.eevblog.com/forum/testgear/the-siglent-sdg2042x-thread/353/
The firmware 17R5 should be the one to downgrade too.
http://www.siglent.com/ENs/gjjrj-xq.aspx?id=1371&tid=15
 
The following users thanked this post: chipss

Offline TechnoTroll

  • Contributor
  • Posts: 12
  • Country: ky
Re: The Siglent SDG2042X Thread
« Reply #877 on: March 01, 2018, 06:13:54 am »
Do a firmware downgrade to and follow the instructions:
https://www.eevblog.com/forum/testgear/the-siglent-sdg2042x-thread/353/
The firmware 17R5 should be the one to downgrade too.
http://www.siglent.com/ENs/gjjrj-xq.aspx?id=1371&tid=15
With janekivi's 23R7 version, if I know the telnet password, can't I just find and delete the bandwidth_update_license line as shown in ?
 

Offline CustomEngineerer

  • Frequent Contributor
  • **
  • Posts: 458
  • Country: us
Re: The Siglent SDG2042X Thread
« Reply #878 on: March 01, 2018, 10:29:12 am »
Yes. Which is why we say there are 2 ways to accomplish the liberation.
 
The following users thanked this post: chipss

Offline BillB

  • Frequent Contributor
  • **
  • Posts: 485
  • Country: us
Re: The Siglent SDG2042X Thread
« Reply #879 on: March 01, 2018, 10:34:54 am »
SDG1000X 30Mhz was hacked to 60Mhz as easily, I heard.

I must be a little slow on the uptake, as I'm not finding much when searching for the SDG1032X solution.  :-/O

I have one that desperately wants to become an SDG1062X.
 

Offline TechnoTroll

  • Contributor
  • Posts: 12
  • Country: ky
Re: The Siglent SDG2042X Thread
« Reply #880 on: March 01, 2018, 11:00:29 pm »
Yes. Which is why we say there are 2 ways to accomplish the liberation.
Thanks, that's what I thought :D
 

Offline ian.ameline

  • Regular Contributor
  • *
  • Posts: 55
  • Country: ca
Re: The Siglent SDG2042X Thread
« Reply #881 on: March 03, 2018, 11:01:41 am »
I'm going to buy one of these -- looks great.

From the teardown pics and various posts here, it seeps that the main CPU (600Mhz Coretex ARM A8) has 128Meg of DDR3 ram - on one Micron DDR3 memory package. But interestingly, the FPGA has *2* of those DDR3 chips -- for 256Meg total. This is way more than the storage needed for 2 x 8M point x 16bit sample waveforms. In fact it is exactly 16 times as much as needed for 2 such waveforms.

Ram is not 0 cost -- I wonder why they have that much ram for the FPGA. Any speculation? 2 ram chips for 2x bandwidth, and same chips to reduce number of different parts on the BOM? Each of those RAM chips can reach 1.6GByte/sec bandwidth, peak, and somewhat less sustained - with 2 of them, that gives probably around 2.6 Gig/second - That's around 1.3MSamples/second total. If the actual sample rate per channel feeding in is 1/4 the sample rate (interpolated), x 2 channels, that would fit comfortably in the bandwidth of those 2 chips.

(It's fairly obvious that they use the same CPU board in many different instruments, so having it standardized is helpful - it has 128Meg of Ram and 256Meg of flash -- more than is needed for this signal generator)

There was well over 128Meg free on the flash, and well over 64Meg of Ram free after the device had booted.

 

Offline Plasmateur

  • Regular Contributor
  • *
  • Posts: 123
  • Country: us
Re: The Siglent SDG2042X Thread
« Reply #882 on: March 03, 2018, 05:13:23 pm »
Did Siglent ever figure out how to get both channels to trigger from a software trigger?

I must have been asking this question for over a year now.

Also, is there any way to do a phase locked pulsed sweep with this?
 

Online tautech

  • Super Contributor
  • ***
  • Posts: 14859
  • Country: nz
  • Taupaki Technologies Ltd. NZ Siglent Distributor
    • Taupaki Technologies Ltd.
Re: The Siglent SDG2042X Thread
« Reply #883 on: March 03, 2018, 05:57:37 pm »
Did Siglent ever figure out how to get both channels to trigger from a software trigger?

I must have been asking this question for over a year now.

Also, is there any way to do a phase locked pulsed sweep with this?
From a Feb FW changelog for SDG5000 models:
http://siglenteu.com/gjjrj-xq.aspx?id=4059&tid=15
d.Manual trigger cannot trigger both channels simultaneously

Not actually what you've asked for but since the current FW is from 2017-09-07 it should be getting close to being added. I've pointed them a couple of times to your request.
Next week I'll ask now things are progressing.
Avid Rabid Hobbyist
 

Online Performa01

  • Frequent Contributor
  • **
  • Posts: 774
  • Country: at
Re: The Siglent SDG2042X Thread
« Reply #884 on: March 03, 2018, 06:43:17 pm »
Also, is there any way to do a phase locked pulsed sweep with this?

Just curious: What is a "pulsed sweep"? And what should it be phase-locked with?
 

Offline bson

  • Supporter
  • ****
  • Posts: 1514
  • Country: us
Re: The Siglent SDG2042X Thread
« Reply #885 on: March 04, 2018, 10:54:46 am »
Ram is not 0 cost -- I wonder why they have that much ram for the FPGA. Any speculation?
If I were to speculate I'd guess all waveforms are generated internally in RAM, then played back.

You can also upload waveforms and refer to them by name later, but I don't know if those are kept in RAM.  It could be it persists them to flash but reloads all waveforms into RAM on startup and expects to find them there during operation, rather than when requested.
 

Offline ian.ameline

  • Regular Contributor
  • *
  • Posts: 55
  • Country: ca
Re: The Siglent SDG2042X Thread
« Reply #886 on: March 05, 2018, 02:21:37 pm »
Ram is not 0 cost -- I wonder why they have that much ram for the FPGA. Any speculation?
If I were to speculate I'd guess all waveforms are generated internally in RAM, then played back.

You can also upload waveforms and refer to them by name later, but I don't know if those are kept in RAM.  It could be it persists them to flash but reloads all waveforms into RAM on startup and expects to find them there during operation, rather than when requested.

Logged in as root while it's running -- free memory is around 85Meg while generating 2 different signals with many harmonics.

The provided arbitrary waveforms are only 32k each (16k samples at 2 bytes/per sample)

The FPGA has 256Meg -- that's where the waveforms will reside while being generated.

The UI app is only using a few percent of the cpu -- even while changing waveforms.

It looks like the CPU board is overkill for this application.

Here is the boot text;

<5>[    0.000000] Linux version 3.2.0-svn6268 (ding@ding-desktop) (gcc version 4.5.3 20110311 (prerelease) (GCC) ) #70 Fri Jul 21 11:47:50 ULAST 2017
<1>[    0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d
<1>[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
<1>[    0.000000] Machine: am335xevm
<4>[    0.000000] Ignoring tag cmdline (using the default kernel command line)
<1>[    0.000000] Memory policy: ECC disabled, Data cache writeback
<7>[    0.000000] On node 0 totalpages: 32768
<7>[    0.000000] free_area_init_node: node 0, pgdat c05b7068, node_mem_map c0602000
<7>[    0.000000]   Normal zone: 256 pages used for memmap
<7>[    0.000000]   Normal zone: 0 pages reserved
<7>[    0.000000]   Normal zone: 32512 pages, LIFO batch:7
<6>[    0.000000] AM335X ES1.0 (neon )
<7>[    0.000000] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
<7>[    0.000000] pcpu-alloc:
  • 0

<1>[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 32512
<5>[    0.000000] Kernel command line: console=ttyO0,115200n8 root=ubi0:rootfs ro ubi.mtd=7,2048 rootfstype=ubifs rootwait=1t ip=none
<6>[    0.000000] PID hash table entries: 512 (order: -1, 2048 bytes)
<6>[    0.000000] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
<6>[    0.000000] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
<6>[    0.000000] Memory: 128MB = 128MB total
<5>[    0.000000] Memory: 123756k/123756k available, 7316k reserved, 0K highmem
<5>[    0.000000] Virtual kernel memory layout:
<5>[    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
<5>[    0.000000]     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
<5>[    0.000000]     vmalloc : 0xc8800000 - 0xff000000   ( 872 MB)
<5>[    0.000000]     lowmem  : 0xc0000000 - 0xc8000000   ( 128 MB)
<5>[    0.000000]     modules : 0xbf000000 - 0xc0000000   (  16 MB)
<5>[    0.000000]       .text : 0xc0008000 - 0xc0529364   (5253 kB)
<5>[    0.000000]       .init : 0xc052a000 - 0xc056c000   ( 264 kB)
<5>[    0.000000]       .data : 0xc056c000 - 0xc05bd350   ( 325 kB)
<5>[    0.000000]        .bss : 0xc05bd374 - 0xc060103c   ( 272 kB)
<6>[    0.000000] NR_IRQS:396
<6>[    0.000000] IRQ: Found an INTC at 0xfa200000 (revision 5.0) with 128 interrupts
<6>[    0.000000] Total of 128 interrupts on 1 active controller
<6>[    0.000000] OMAP clockevent source: GPTIMER2 at 25000000 Hz
<4>[    0.000000] omap_dm_timer_switch_src: Switching to HW default clocksource(sys_clkin_ck) for timer1, this may impact timekeeping in low power state
<6>[    0.000000] OMAP clocksource: GPTIMER1 at 25000000 Hz
<6>[    0.000000] sched_clock: 32 bits at 25MHz, resolution 40ns, wraps every 171798ms
<6>[    0.000000] Console: colour dummy device 80x30
<6>[    0.000209] Calibrating delay loop... 718.02 BogoMIPS (lpj=3590144)
<6>[    0.057098] pid_max: default: 32768 minimum: 301
<6>[    0.057279] Mount-cache hash table entries: 512
<6>[    0.057665] CPU: Testing write buffer coherency: ok
<6>[    0.057741] ftrace: allocating 14556 entries in 43 pages
<4>[    0.109666] omap_hwmod: gfx: failed to hardreset
<4>[    0.125747] omap_hwmod: pruss: failed to hardreset
<6>[    0.126911] print_constraints: dummy:
<6>[    0.127220] NET: Registered protocol family 16
<6>[    0.129423] OMAP GPIO hardware version 0.1
<1>[    0.131682] am335x_evm_init()++
<6>[    0.131906] omap_mux_init: Add partition: #1: core, flags: 0
<1>[    0.134052] am335x_evm_i2c_init()++
<4>[    0.134295]  omap_i2c.1: alias fck already exists
<1>[    0.134502] am335x_evm_i2c_init()--
<1>[    0.134629] da8xx_panel_power_ctrl()++
<1>[    0.134668] back light switch = 1
<1>[    0.134690] da8xx_panel_power_ctrl()--
<1>[    0.135010] am335x_evm_init()--
<4>[    0.135304]  omap2_mcspi.1: alias fck already exists
<4>[    0.135525]  omap2_mcspi.2: alias fck already exists
<4>[    0.135792]  edma.0: alias fck already exists
<4>[    0.135814]  edma.0: alias fck already exists
<4>[    0.135833]  edma.0: alias fck already exists
<6>[    0.152750] bio: create slab <bio-0> at 0
<5>[    0.154907] SCSI subsystem initialized
<6>[    0.156705] usbcore: registered new interface driver usbfs
<6>[    0.157034] usbcore: registered new interface driver hub
<6>[    0.157293] usbcore: registered new device driver usb
<6>[    0.157906] omap_i2c omap_i2c.1: bus 1 rev2.4.0 at 100 kHz
<6>[    0.159687] tps65910 1-002d: JTAGREVNUM 0x0
<6>[    0.162075] print_constraints: VRTC:
<6>[    0.163517] print_constraints: VIO: at 1500 mV
<6>[    0.165823] print_constraints: VDD1: 600 <--> 1500 mV at 1262 mV normal
<6>[    0.168126] print_constraints: VDD2: 600 <--> 1500 mV at 1137 mV normal
<6>[    0.169155] print_constraints: VDD3: 5000 mV
<6>[    0.170565] print_constraints: VDIG1: at 1800 mV
<6>[    0.171980] print_constraints: VDIG2: at 1800 mV
<6>[    0.173394] print_constraints: VPLL: at 1800 mV
<6>[    0.174801] print_constraints: VDAC: at 1800 mV
<6>[    0.176228] print_constraints: VAUX1: at 1800 mV
<6>[    0.177636] print_constraints: VAUX2: at 3300 mV
<6>[    0.179069] print_constraints: VAUX33: at 3300 mV
<6>[    0.180482] print_constraints: VMMC: at 3300 mV
<4>[    0.180974] tps65910 1-002d: No interrupt support, no core IRQ
<6>[    0.182607] cfg80211: Calling CRDA to update world regulatory domain
<6>[    0.183254] Switching to clocksource gp timer
<6>[    0.204259] NET: Registered protocol family 2
<6>[    0.204472] IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
<6>[    0.204764] TCP established hash table entries: 4096 (order: 3, 32768 bytes)
<6>[    0.204856] TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
<6>[    0.204912] TCP: Hash tables configured (established 4096 bind 4096)
<6>[    0.204925] TCP reno registered
<6>[    0.204938] UDP hash table entries: 256 (order: 0, 4096 bytes)
<6>[    0.204962] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
<6>[    0.205135] NET: Registered protocol family 1
<6>[    0.205418] RPC: Registered named UNIX socket transport module.
<6>[    0.205431] RPC: Registered udp transport module.
<6>[    0.205441] RPC: Registered tcp transport module.
<6>[    0.205450] RPC: Registered tcp NFSv4.1 backchannel transport module.
<3>[    0.206177] cpuidle-am33xx cpuidle-am33xx.0: failed to register driver
<6>[    0.213550] Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
<6>[    0.213891] msgmni has been set to 241
<6>[    0.214558] io scheduler noop registered
<6>[    0.214573] io scheduler deadline registered
<6>[    0.214654] io scheduler cfq registered (default)
<6>[    0.215792] omap_uart.0: ttyO0 at MMIO 0x44e09000 (irq = 72) is a OMAP UART0
<6>[    0.766297] console [ttyO0] enabled
<6>[    0.770438] omap_uart.1: ttyO1 at MMIO 0x48022000 (irq = 73) is a OMAP UART1
<6>[    0.778228] omap_uart.2: ttyO2 at MMIO 0x48024000 (irq = 74) is a OMAP UART2
<6>[    0.785977] omap_uart.3: ttyO3 at MMIO 0x481a6000 (irq = 44) is a OMAP UART3
<6>[    0.793704] omap_uart.4: ttyO4 at MMIO 0x481a8000 (irq = 45) is a OMAP UART4
<6>[    0.801387] omap_uart.5: ttyO5 at MMIO 0x481aa000 (irq = 46) is a OMAP UART5
<6>[    0.818601] brd: module loaded
<6>[    0.826897] loop: module loaded
<6>[    0.830261] at24 1-0051: 32768 byte 24c256 EEPROM, writable, 64 bytes/write
<6>[    0.893296] No daughter card found
<6>[    0.896889] at24 1-0050: 32768 byte 24c256 EEPROM, writable, 64 bytes/write
<1>[    0.904159] am335x_evm_setup()++
<4>[    0.963295] AM335X: EVM Config read fail: -110
<6>[    0.967924] No board detected, using GPBoard 1.1A as default
<6>[    0.973972] The board is general purpose EVM in profile 0
<3>[    0.979597] Found invalid GP EVM revision, falling back to Rev1.1A
<1>[    0.986050] -------siglent_fpga_init++
<1>[    0.990055] -------siglent_fpga_init--
<4>[    0.994756]  da8xx_lcdc.0: alias fck already exists
<1>[    1.000284] evm_nand_init()++
<6>[    1.004003] omap-gpmc omap-gpmc: GPMC revision 6.0
<6>[    1.009005] Registering NAND on CS0
<1>[    1.013236] evm_nand_init()--
<1>[    1.017764] haptics_init()++
<1>[    1.021746] haptics_init()--
<1>[    1.024794] out_triger_gpio_init()++
<1>[    1.028557] out_triger_gpio_init()--
<1>[    1.032748] am335x_evm_setup()--
<3>[    1.037674] mtdoops: mtd device (mtddev=name/number) must be supplied
<6>[    1.044801] omap2-nand driver initializing
<6>[    1.049388] ONFI flash detected
<6>[    1.052791] ONFI param page 0 valid
<6>[    1.056465] NAND device: Manufacturer ID: 0x2c, Chip ID: 0xda (Micron MT29F2G08ABAEAWP)
<5>[    1.065152] Creating 12 MTD partitions on "omap2-nand.0":
<5>[    1.070796] 0x000000000000-0x000000020000 : "SPL"
<5>[    1.077162] 0x000000020000-0x000000040000 : "SPL.backup1"
<5>[    1.084113] 0x000000040000-0x000000060000 : "SPL.backup2"
<5>[    1.091002] 0x000000060000-0x000000080000 : "SPL.backup3"
<5>[    1.097969] 0x000000080000-0x000000260000 : "U-Boot"
<5>[    1.105199] 0x000000260000-0x000000280000 : "U-Boot Env"
<5>[    1.112014] 0x000000280000-0x000000580000 : "Manufacturedata"
<5>[    1.120550] 0x000000580000-0x000003080000 : "rootfs"
<5>[    1.144892] 0x000003080000-0x000003680000 : "kerneldata"
<5>[    1.154142] 0x000003680000-0x000006880000 : "firmdata0"
<5>[    1.181575] 0x000006880000-0x000009a80000 : "firmdata1"
<5>[    1.208986] 0x000009a80000-0x000010000000 : "datafs"
<6>[    1.257741] OneNAND driver initializing
<5>[    1.262444] UBI: attaching mtd7 to ubi0
<5>[    1.266497] UBI: physical eraseblock size:   131072 bytes (128 KiB)
<5>[    1.273026] UBI: logical eraseblock size:    126976 bytes
<5>[    1.278661] UBI: smallest flash I/O unit:    2048
<5>[    1.283570] UBI: sub-page size:              512
<5>[    1.288379] UBI: VID header offset:          2048 (aligned 2048)
<5>[    1.294646] UBI: data offset:                4096
<5>[    1.709829] UBI: max. sequence number:       160
<4>[    1.728356] UBI warning: print_rsvd_warning: cannot reserve enough PEBs for bad PEB handling, reserved 9, need 12
<5>[    1.740044] UBI: attached mtd7 to ubi0
<5>[    1.743992] UBI: MTD device name:            "rootfs"
<5>[    1.749254] UBI: MTD device size:            43 MiB
<5>[    1.754346] UBI: number of good PEBs:        344
<5>[    1.759153] UBI: number of bad PEBs:         0
<5>[    1.763789] UBI: number of corrupted PEBs:   0
<5>[    1.768417] UBI: max. allowed volumes:       128
<5>[    1.773224] UBI: wear-leveling threshold:    4096
<5>[    1.778132] UBI: number of internal volumes: 1
<5>[    1.782758] UBI: number of user volumes:     1
<5>[    1.787393] UBI: available PEBs:             0
<5>[    1.792020] UBI: total number of reserved PEBs: 344
<5>[    1.797109] UBI: number of PEBs reserved for bad PEB handling: 9
<5>[    1.803375] UBI: max/mean erase counter: 2/0
<5>[    1.807821] UBI: image sequence number:  769161752
<5>[    1.812881] UBI: background thread "ubi_bgt0d" started, PID 485
<6>[    1.863341] davinci_mdio davinci_mdio.0: davinci mdio revision 1.6
<6>[    1.869792] davinci_mdio davinci_mdio.0: detected phy mask bfffffff
<1>[    1.876557] bus->id = 0, addr= 30
<1>[    1.880211] 11--
<6>[    1.882341] davinci_mdio.0: probed
<6>[    1.885927] davinci_mdio davinci_mdio.0: phy[30]: device 0:1e, driver unknown
<6>[    1.893749] usbcore: registered new interface driver rt2800usb
<6>[    1.899829] Initializing USB Mass Storage driver...
<6>[    1.905123] usbcore: registered new interface driver usb-storage
<6>[    1.911383] USB Mass Storage support registered.
<6>[    1.916664] mousedev: PS/2 mouse device common for all mice
<6>[    1.922474] i2c /dev entries driver
<6>[    1.927250] OMAP Watchdog Timer Rev 0x01: initial timeout 60 sec
<7>[    1.934071] Registered led device: omap3evm::leda
<6>[    1.934311] TCP cubic registered
<6>[    1.937680] NET: Registered protocol family 17
<6>[    1.942444] NET: Registered protocol family 33
<6>[    1.947131] lib80211: common routines for IEEE802.11 drivers
<7>[    1.953030] lib80211_crypt: registered algorithm 'NULL'
<7>[    1.953041] lib80211_crypt: registered algorithm 'WEP'
<7>[    1.953052] lib80211_crypt: registered algorithm 'CCMP'
<7>[    1.953062] lib80211_crypt: registered algorithm 'TKIP'
<5>[    1.953073] Registering the dns_resolver key type
<6>[    1.958073] VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 3
<6>[    1.966077] ThumbEE CPU extension supported.
<4>[    1.970586] mux: Failed to setup hwmod io irq -22
<6>[    1.976103] Power Management for AM33XX family
<6>[    1.980790] clock: disabling unused clocks to save power
<6>[    1.987994] Detected MACID=c8:fd:19:d1:4f:32
<5>[    2.067310] UBIFS: recovery needed
<5>[    2.275817] UBIFS: recovery deferred
<5>[    2.279564] UBIFS: mounted UBI device 0, volume 0, name "rootfs"
<5>[    2.285837] UBIFS: mounted read-only
<5>[    2.289563] UBIFS: file system size:   40632320 bytes (39680 KiB, 38 MiB, 320 LEBs)
<5>[    2.297556] UBIFS: journal size:       9023488 bytes (8812 KiB, 8 MiB, 72 LEBs)
<5>[    2.305183] UBIFS: media format:       w4/r0 (latest is w4/r0)
<5>[    2.311259] UBIFS: default compressor: lzo
<5>[    2.315537] UBIFS: reserved for root:  0 bytes (0 KiB)
<6>[    2.322725] VFS: Mounted root (ubifs filesystem) readonly on device 0:12.
<6>[    2.330223] Freeing init memory: 264K
<5>[    4.120378] UBI: attaching mtd11 to ubi1
<5>[    4.124536] UBI: physical eraseblock size:   131072 bytes (128 KiB)
<5>[    4.131066] UBI: logical eraseblock size:    126976 bytes
<5>[    4.136701] UBI: smallest flash I/O unit:    2048
<5>[    4.141599] UBI: sub-page size:              512
<5>[    4.146418] UBI: VID header offset:          2048 (aligned 2048)
<5>[    4.152675] UBI: data offset:                4096
<5>[    5.125439] UBI: max. sequence number:       580
<5>[    5.153424] UBI: attached mtd11 to ubi1
<5>[    5.157440] UBI: MTD device name:            "datafs"
<5>[    5.162702] UBI: MTD device size:            101 MiB
<5>[    5.167889] UBI: number of good PEBs:        812
<5>[    5.172697] UBI: number of bad PEBs:         0
<5>[    5.177334] UBI: number of corrupted PEBs:   0
<5>[    5.181962] UBI: max. allowed volumes:       128
<5>[    5.186779] UBI: wear-leveling threshold:    4096
<5>[    5.191678] UBI: number of internal volumes: 1
<5>[    5.196315] UBI: number of user volumes:     1
<5>[    5.200941] UBI: available PEBs:             0
<5>[    5.205578] UBI: total number of reserved PEBs: 812
<5>[    5.210657] UBI: number of PEBs reserved for bad PEB handling: 32
<5>[    5.217015] UBI: max/mean erase counter: 3/1
<5>[    5.221461] UBI: image sequence number:  264443814
<5>[    5.226480] UBI: background thread "ubi_bgt1d" started, PID 558
<5>[    5.340002] UBIFS: recovery needed
<5>[    5.511354] UBIFS: recovery completed
<5>[    5.515220] UBIFS: mounted UBI device 1, volume 0, name "rootfs"
<5>[    5.521483] UBIFS: file system size:   97136640 bytes (94860 KiB, 92 MiB, 765 LEBs)
<5>[    5.529477] UBIFS: journal size:       9023488 bytes (8812 KiB, 8 MiB, 72 LEBs)
<5>[    5.537105] UBIFS: media format:       w4/r0 (latest is w4/r0)
<5>[    5.543182] UBIFS: default compressor: lzo
<5>[    5.547456] UBIFS: reserved for root:  0 bytes (0 KiB)
<5>[    5.617689] UBI: attaching mtd9 to ubi2
<5>[    5.621712] UBI: physical eraseblock size:   131072 bytes (128 KiB)
<5>[    5.628309] UBI: logical eraseblock size:    126976 bytes
<5>[    5.633946] UBI: smallest flash I/O unit:    2048
<5>[    5.638845] UBI: sub-page size:              512
<5>[    5.643665] UBI: VID header offset:          2048 (aligned 2048)
<5>[    5.649922] UBI: data offset:                4096
<5>[    6.131575] UBI: max. sequence number:       25
<5>[    6.159784] UBI: attached mtd9 to ubi2
<5>[    6.163773] UBI: MTD device name:            "firmdata0"
<5>[    6.169308] UBI: MTD device size:            50 MiB
<5>[    6.174401] UBI: number of good PEBs:        400
<5>[    6.179208] UBI: number of bad PEBs:         0
<5>[    6.183846] UBI: number of corrupted PEBs:   0
<5>[    6.188473] UBI: max. allowed volumes:       128
<5>[    6.193290] UBI: wear-leveling threshold:    4096
<5>[    6.198188] UBI: number of internal volumes: 1
<5>[    6.202814] UBI: number of user volumes:     1
<5>[    6.207450] UBI: available PEBs:             0
<5>[    6.212077] UBI: total number of reserved PEBs: 400
<5>[    6.217166] UBI: number of PEBs reserved for bad PEB handling: 16
<5>[    6.223523] UBI: max/mean erase counter: 2/1
<5>[    6.227970] UBI: image sequence number:  879522226
<5>[    6.232982] UBI: background thread "ubi_bgt2d" started, PID 583
<5>[    6.335449] UBIFS: recovery needed
<5>[    6.438424] UBIFS: recovery deferred
<5>[    6.442166] UBIFS: mounted UBI device 2, volume 0, name "firmdata0"
<5>[    6.448721] UBIFS: mounted read-only
<5>[    6.452449] UBIFS: file system size:   46854144 bytes (45756 KiB, 44 MiB, 369 LEBs)
<5>[    6.460443] UBIFS: journal size:       9023488 bytes (8812 KiB, 8 MiB, 72 LEBs)
<5>[    6.468071] UBIFS: media format:       w4/r0 (latest is w4/r0)
<5>[    6.474156] UBIFS: default compressor: lzo
<5>[    6.478422] UBIFS: reserved for root:  0 bytes (0 KiB)
<4>[    7.973305] sched: RT throttling activated
<3>[    9.265308]
<3>[    9.265318] CPSW phy found : id is : 0x20005c90
<3>[    9.272326] PHY 0:01 not found
<1>[    9.444391] gpib_usb_init
<6>[    9.461740] usbcore: registered new interface driver usb-gpib
<6>[   11.264006] PHY: 0:1e - Link is Up - 100/Full
<6>[   17.844018] musb-hdrc: version 6.0, ?dma?, otg (peripheral+host)
<6>[   17.917193] musb-ti81xx musb-ti81xx: musb0, board_mode=0x13, plat_mode=0x3
<6>[   17.949020] musb-hdrc musb-hdrc.0: dma type: pio
<7>[   17.968437] musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine, bulk split, HB-ISO Rx, HB-ISO Tx, SoftConn)
<7>[   17.968469] musb-hdrc: MHDRC RTL version 2.0
<7>[   17.968480] musb-hdrc: setup fifo_mode 4
<7>[   17.968512] musb-hdrc: 28/31 max ep, 16384/16384 memory
<6>[   17.974834] musb-hdrc musb-hdrc.0: USB OTG mode controller at c8aa2000 using PIO, IRQ 18
<6>[   18.002175] musb-ti81xx musb-ti81xx: musb1, board_mode=0x13, plat_mode=0x1
<6>[   18.013720] musb-hdrc musb-hdrc.1: dma type: pio
<7>[   18.032897] musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine, bulk split, HB-ISO Rx, HB-ISO Tx, SoftConn)
<7>[   18.032929] musb-hdrc: MHDRC RTL version 2.0
<7>[   18.032941] musb-hdrc: setup fifo_mode 4
<7>[   18.032972] musb-hdrc: 28/31 max ep, 16384/16384 memory
<6>[   18.033027] musb-hdrc musb-hdrc.1: MUSB HDRC host driver
<6>[   18.038804] musb-hdrc musb-hdrc.1: new USB bus registered, assigned bus number 1
<6>[   18.046663] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
<6>[   18.053761] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
<6>[   18.061306] usb usb1: Product: MUSB HDRC host driver
<6>[   18.066499] usb usb1: Manufacturer: Linux 3.2.0-svn6268 musb-hcd
<6>[   18.072758] usb usb1: SerialNumber: musb-hdrc.1
<6>[   18.094532] hub 1-0:1.0: USB hub found
<6>[   18.098518] hub 1-0:1.0: 1 port detected
<6>[   18.113447] musb-hdrc musb-hdrc.1: USB Host mode controller at c8aa4800 using PIO, IRQ 19
<6>[   18.343989] da8xx_lcdc da8xx_lcdc.0: GLCD: Found HANSTAR_HSD070IDW1_A panel
<1>[   19.189894] usbtmc_bind+++
<6>[   19.200266] SIGLENT_DEV: SIGLENT_DEV, version: 2007 OCT 06
<6>[   19.206089] musb-hdrc musb-hdrc.0: MUSB HDRC host driver
<6>[   19.211669] musb-hdrc musb-hdrc.0: new USB bus registered, assigned bus number 2
<6>[   19.219528] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002
<6>[   19.226626] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
<6>[   19.234170] usb usb2: Product: MUSB HDRC host driver
<6>[   19.239346] usb usb2: Manufacturer: Linux 3.2.0-svn6268 musb-hcd
<6>[   19.245615] usb usb2: SerialNumber: musb-hdrc.0
<6>[   19.271157] hub 2-0:1.0: USB hub found
<6>[   19.275165] hub 2-0:1.0: 1 port detected
<1>[   19.293033] usbtmc_open()++
<1>[   19.296030] dev->usbtmc_cdev_open ret = 0
<1>[   19.300205] ret = 0
<1>[   19.302386] usbtmc_open--
 

Offline Dwaine

  • Frequent Contributor
  • **
  • Posts: 256
  • Country: ca
Re: The Siglent SDG2042X Thread
« Reply #887 on: March 05, 2018, 06:35:26 pm »
Fantastic.  That means Siglent can add graphing to the frequency counter.  It would be nice to use that colour screen. 
 

Offline ian.ameline

  • Regular Contributor
  • *
  • Posts: 55
  • Country: ca
Re: The Siglent SDG2042X Thread
« Reply #888 on: March 06, 2018, 01:47:16 am »
Fantastic.  That means Siglent can add graphing to the frequency counter.  It would be nice to use that colour screen.

I don't think there are any cpu, RAM, or storage  limitations preventing that. It is just a matter of designing the UI and writing the code.
(A non trivial amount of work -- ie not days, but weeks) Logging the frequency  over a considerable time should also not pose any insurmountable challenges either. (File could be written to USB key or internal storage.

Internal storage is 256Meg of single level (SLC) flash. (as opposed to MLC) SLC has far better write endurance.

Sifting through the binary code, it looks like the main app is written in C++x11 (The binary for that is around 8.5 megabytes). The binary file for the FPGA is 1.8 megabytes.

There also appears some parts of nfs running -- I'll see if I can mount the internal storage as an nfs share from another computer.





 

Offline ian.ameline

  • Regular Contributor
  • *
  • Posts: 55
  • Country: ca
Re: The Siglent SDG2042X Thread
« Reply #889 on: March 06, 2018, 01:51:03 am »
Here is the list of running processes; (in order of CPU usage - running top)

Mem: 42460K used, 81560K free, 0K shrd, 0K buff, 15020K cached
CPU:   0% usr  30% sys   0% nic  69% idle   0% io   0% irq   0% sirq
Load average: 0.00 0.01 0.05 1/64 825
  PID  PPID USER     STAT   VSZ %MEM %CPU COMMAND
  612     2 root     RW       0   0%  27% [kworker/u:2]
  533     1 root     S     151m 125%   4% ./sdg2000.app
  825   778 root     R     2844   2%   0% top
  597     2 root     SW       0   0%   0% [kworker/0:2]
  536     1 root     S     2844   2%   0% telnetd
  778   536 root     S     2844   2%   0% -sh
  535     1 root     S     2844   2%   0% -/bin/sh
    1     0 root     S     2668   2%   0% init       
  537     1 1        S     1788   1%   0% portmap
    3     2 root     SW       0   0%   0% [ksoftirqd/0]
    5     2 root     SW       0   0%   0% [kworker/u:0]
  558     2 root     SW       0   0%   0% [ubi_bgt1d]
  165     2 root     SW       0   0%   0% [sync_supers]
    2     0 root     SW       0   0%   0% [kthreadd]
    6     2 root     SW<      0   0%   0% [khelper]
  167     2 root     SW       0   0%   0% [bdi-default]
  169     2 root     SW<      0   0%   0% [kblockd]
  181     2 root     SW<      0   0%   0% [omap2_mcspi]
  192     2 root     SW       0   0%   0% [khubd]
  225     2 root     SW<      0   0%   0% [cfg80211]
  226     2 root     SW       0   0%   0% [kworker/0:1]
  309     2 root     SW<      0   0%   0% [rpciod]
  320     2 root     SW       0   0%   0% [kswapd0]
  321     2 root     SW       0   0%   0% [fsnotify_mark]
  322     2 root     SW<      0   0%   0% [nfsiod]
  323     2 root     SW<      0   0%   0% [crypto]
  333     2 root     SW<      0   0%   0% [OMAP UART0]
  335     2 root     SW<      0   0%   0% [OMAP UART1]
  337     2 root     SW<      0   0%   0% [OMAP UART2]
  339     2 root     SW<      0   0%   0% [OMAP UART3]
  341     2 root     SW<      0   0%   0% [OMAP UART4]
  343     2 root     SW<      0   0%   0% [OMAP UART5]
  421     2 root     SW       0   0%   0% [mtdblock0]
  426     2 root     SW       0   0%   0% [mtdblock1]
  431     2 root     SW       0   0%   0% [mtdblock2]
  436     2 root     SW       0   0%   0% [mtdblock3]
  441     2 root     SW       0   0%   0% [mtdblock4]
  446     2 root     SW       0   0%   0% [mtdblock5]
  451     2 root     SW       0   0%   0% [mtdblock6]
  456     2 root     SW       0   0%   0% [mtdblock7]
  461     2 root     SW       0   0%   0% [mtdblock8]
  466     2 root     SW       0   0%   0% [mtdblock9]
  471     2 root     SW       0   0%   0% [mtdblock10]
  476     2 root     SW       0   0%   0% [mtdblock11]
  485     2 root     SW       0   0%   0% [ubi_bgt0d]
  564     2 root     SW       0   0%   0% [ubifs_bgt1_0]
  583     2 root     SW       0   0%   0% [ubi_bgt2d]
  704     2 root     SW<      0   0%   0% [musb-hdrc.0]
  710     2 root     SW<      0   0%   0% [musb-hdrc.1]
 

Offline ian.ameline

  • Regular Contributor
  • *
  • Posts: 55
  • Country: ca
Re: The Siglent SDG2042X Thread
« Reply #890 on: March 06, 2018, 02:13:28 am »
Anyone poking around in their own SDG, I recommend being *very* careful. There are a few scripts that appear designed to install new versions of the firmware from USB or other devices - but they are not very well written scripts -- they completely erase the nand *before* checking if there is a good replacement image available. It appears easy to brick your device if you are not careful. (I suspect typing "reboot" from the command line while there is a USB key present might be enough to do it - I don't want to try to test this theory.)

Fortunately for us hackers, there are no digital signature checks on new firmware versions. (If I were running their firmware development, things would be a little tighter :-) But there appears to be very little thought given to security for these things -- I would not expose them to the internet without a firewall. But they are nicely hackable without even physically opening the box. (Many thanks to the person who made logging in as root possible.)
 
That said, I'm quite impressed with this device -- it can generate some very complex waveforms, and they look *very* clean. It seems well made, and the software appears to work well. I'm quite happy with my purchase.
 
The following users thanked this post: bmdaly

Offline BillB

  • Frequent Contributor
  • **
  • Posts: 485
  • Country: us
Re: The Siglent SDG2042X Thread
« Reply #891 on: March 06, 2018, 03:30:31 am »
Anyone poking around in their own SDG, I recommend being *very* careful. There are a few scripts that appear designed to install new versions of the firmware from USB or other devices - but they are not very well written scripts -- they completely erase the nand *before* checking if there is a good replacement image available. It appears easy to brick your device if you are not careful. (I suspect typing "reboot" from the command line while there is a USB key present might be enough to do it - I don't want to try to test this theory.)

Ian, which scripts?  I've been poking around on my SDG1032X, which has a very similar layout to the SDG2000X (i.e. running ./sdg1000.app instead).  I can say that so far, rebooting through console hasn't bricked my device yet.   :phew:

 

Offline rf-loop

  • Super Contributor
  • ***
  • Posts: 3021
  • Country: fi
  • Starting with DLL21
Re: The Siglent SDG2042X Thread
« Reply #892 on: March 06, 2018, 04:31:41 am »
SDG1000X 30Mhz was hacked to 60Mhz as easily, I heard.

I must be a little slow on the uptake, as I'm not finding much when searching for the SDG1032X solution.  :-/O

I have one that desperately wants to become an SDG1062X.

Yes but this thread is for SDG2000X (SDG2042X)

Nice things for SDG1000X can find its own thread.

I think it is wise to keep these models separate for avoid confusion and mistakes (also we need think readers with different knowledge level) even when they have some similarities if we think some "adjustments" for performance.
« Last Edit: March 06, 2018, 09:26:19 am by rf-loop »
If practice and theory is not equal it tells that used application of theory  is wrong or the theory itself is wrong.
It is much easier to think an apple fall to the ground than to think that the earth and the apple will begin to move toward each other and collide.
 

Offline ian.ameline

  • Regular Contributor
  • *
  • Posts: 55
  • Country: ca
Re: The Siglent SDG2042X Thread
« Reply #893 on: March 06, 2018, 05:00:51 am »
Ian, which scripts?  I've been poking around on my SDG1032X, which has a very similar layout to the SDG2000X (i.e. running ./sdg1000.app instead).  I can say that so far, rebooting through console hasn't bricked my device yet.   :phew:

Glad to hear you don't have a brick... yet :-)

I'd avoid anything in /usr/sbin - this is the stuff that formats and overwrites flash - even nandtest (I dumped the binary and started to disassemble) doesn't look safe.

/usr/lib/siglentlib.sh is the script in question -- have a look -- it could be a little less eager to flash_erase in my opinion...


 

Offline Dwaine

  • Frequent Contributor
  • **
  • Posts: 256
  • Country: ca
Re: The Siglent SDG2042X Thread
« Reply #894 on: March 06, 2018, 05:31:10 am »
It's a very well made device.   I had my unit for about six months and really enjoy using it.  Siglent really hit a home run with this device.

Is there a web server installed that we could use?
 

Offline ian.ameline

  • Regular Contributor
  • *
  • Posts: 55
  • Country: ca
Re: The Siglent SDG2042X Thread
« Reply #895 on: March 06, 2018, 06:10:30 am »
Just for shits and giggles I decided to check the accuracy...

I have a relatively recently calibrated HP34401A (Last August cal) (Running with 10G input impedance, slow 6 digit mode)

The SDG was calibrated at the factory in December.

Everything warmed up for 2 hours, 21 degrees (C), 50% humidity.

The SDG2042X on channel 1, (DC Offset) is within 0.1% accuracy from 50mv to 10v. Below 50mv, it gets as bad as 0.5%. Channel 2 is within 0.2% from 50mv to 10V, and similar to ch 1 below that. At 100mv, both channels are reading 100.002x mv (last digit is not reliable IMO) -- That's as close as it got -- and not too shabby - pretty much at the limit of the accuracy of the 34401A.

(Below 100mv, the SDG is  slightly lower than claimed output -- above 100mv it is slightly higher. This was true for both channels.)

The specs for the SDG for DC offset are 1% +2mv. So these measurements are quite well within spec for the SDG.

Obviously a sample of 1 does not make for good statistics :-)

For frequency accuracy, at 100.000 000khz The internal counter on the SDG agrees - 100.000 00 khz. The HP34401A says 100.000 3 khz. The 34401 is specd at +-0.01% > 40khz -  (ie +-0.01khz for 100khz) so that reading is well within spec for the 34401. The internal counter specs for the SDG are 1 ppm or +- 0.000 1 khz for 100khz. So I'd tend to think that the counter in the SDG is closer to the truth here - but I'd expect it to agree with its output -- they're very likely using the same clock.

I'll check the ac voltages with the 34401 and see how they do.
 

Offline ian.ameline

  • Regular Contributor
  • *
  • Posts: 55
  • Country: ca
Re: The Siglent SDG2042X Thread
« Reply #896 on: March 06, 2018, 06:22:34 am »
It's a very well made device.   I had my unit for about six months and really enjoy using it.  Siglent really hit a home run with this device.

Is there a web server installed that we could use?

There is definitely not one running on the SDG device. The CPU and OS and hardware resources of the device would support running one if Siglent decided to put in the r&d effort.
 

Offline ian.ameline

  • Regular Contributor
  • *
  • Posts: 55
  • Country: ca
Re: The Siglent SDG2042X Thread
« Reply #897 on: March 06, 2018, 08:13:57 am »
AC performance appears excellent -- at 3.112 V P-P sine wave, I measure 1.100 VAC RMS from 50hz to 100khz, +- 0.25%

(Spec sheet says +- 1% +1mv at 10hhz, 2.5v p-p. So once again, significantly exceeding the accuracy of the spec.)

Interestingly the HP34401A claims to measure frequencies up to 300khz. With slightly higher voltages (12vp-p), I was able to get accurate frequency counts from it up to 1.9Mhz! (dropping the voltage affected things quite a bit, and not even 20v p-p would get an accurate reading at 2.0 mhz)

The 300khz claim is across a very wide range of voltages... 100mv to 750v.

 

Offline Plasmateur

  • Regular Contributor
  • *
  • Posts: 123
  • Country: us
Re: The Siglent SDG2042X Thread
« Reply #898 on: March 07, 2018, 01:24:40 am »
Did Siglent ever figure out how to get both channels to trigger from a software trigger?

I must have been asking this question for over a year now.

Also, is there any way to do a phase locked pulsed sweep with this?
From a Feb FW changelog for SDG5000 models:
http://siglenteu.com/gjjrj-xq.aspx?id=4059&tid=15
d.Manual trigger cannot trigger both channels simultaneously



Not actually what you've asked for but since the current FW is from 2017-09-07 it should be getting close to being added. I've pointed them a couple of times to your request.
Next week I'll ask now things are progressing.

Thanks! As for the other question. Do think they would be able add this functionality?

Sweep + Burst, phase locked.

Example,

I am able to sweep from 1MHz to 10MHz over some set amount of time, and that sweep is triggered?
 

Online tautech

  • Super Contributor
  • ***
  • Posts: 14859
  • Country: nz
  • Taupaki Technologies Ltd. NZ Siglent Distributor
    • Taupaki Technologies Ltd.
Re: The Siglent SDG2042X Thread
« Reply #899 on: March 07, 2018, 08:42:57 pm »
Did Siglent ever figure out how to get both channels to trigger from a software trigger?

I must have been asking this question for over a year now.

Also, is there any way to do a phase locked pulsed sweep with this?
From a Feb FW changelog for SDG5000 models:
http://siglenteu.com/gjjrj-xq.aspx?id=4059&tid=15
d.Manual trigger cannot trigger both channels simultaneously



Not actually what you've asked for but since the current FW is from 2017-09-07 it should be getting close to being added. I've pointed them a couple of times to your request.
Next week I'll ask now things are progressing.

Thanks! As for the other question. Do think they would be able add this functionality?

Sweep + Burst, phase locked.

Example,

I am able to sweep from 1MHz to 10MHz over some set amount of time, and that sweep is triggered?
I tried doing this with a SDG1032X today with partial success by controlling the sweep from the Aux input triggered from the 2nd channel by using a continuous pulse with a short duty cycle to activate a burst.

The Sweep needs be set to external source however while the sweep was doing its thing correctly and at the prescribed intervals, between the sweeps was a continuous fixed frequency sine wave.  :-//
Maybe I just cocked something up.

Would 'Gated Sweep' be a better description of what you'd like ?

Avid Rabid Hobbyist
 
The following users thanked this post: Plasmateur


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf