My DD 2.0 with a 3dB attenuator is fine for 8" CAV disks and 8/12" CLV, but I was trying to capture THX Wow! and A Video Standard's signals and they were too strong causing interference patterns etc. It would be nice to have an adjustment on the board I could use, or even better (but far more difficult!) would be an electronic gain control controlled by a DAC on the board.

This should be 28.6 - this is only an error in the GUI form text, the actual sampling rate is correct.

Following the ADS825 evaluation board schematic, it should improve the clock edges slightly if a 40-50Kohm resistor is placed between the ADC clock input pin and ground. I've tested this on a board and the signal edges show a slight (but not massively significant) improvement; probably worth adding to the next board revision though.

When using the pre-made programming configurations in Quartus - you get the following error:

Warning (11655): Can't locate programming file DomesdayDuplicator.jic in /home/sdi/github/DomesdayDuplicator/DE0-NANO/DomesdayDuplicator/.

Looks like the programming file does not use relative paths and needs to be modified.

Originally posted by @simoninns in #60 (comment)

1. Start capture
2. Stop capture

The UI becomes unresponsive (with pinwheel/beach-ball) for about 10 seconds, then functions normally.

When run from Terminal, the delay occurs between these two debug messages:

UsbCapture::runDiskBuffers(): Thread stopped
UsbCapture::freeDiskBuffers(): Freeing disk buffer memory

If the auto-capture detects that the disc has stepped backwards during capture the error is shown in the debug; but no GUI error is provided to the user.

Debug error comes from PlayerControl::acStateWaitForEndAddress

1. Open preferences dialog
2. Click 'Save'

The program immediately exits. Preferences are saved, though.

From the contents of the error details, I suspect that the problem occurs when player control is not being used.

On Ubuntu 18.04, the following messages are shown in the console:

ConfigurationDialog::on_buttonBox_accepted(): Configuration changed
MainWindow::configurationChangedSignalHandler(): Configuration has been changed
ConfigurationDialog::saveConfiguration(): Saving configuration
MainWindow::startPlayerControl(): Getting player type
MainWindow::startPlayerControl(): Warning: Player type is not configured
PlayerControl::configurePlayerCommunication(): Called
PlayerControl::configurePlayerCommunication(): Peforming reconnection attempt
PlayerCommunication::connect(): Disconnecting from player
Segmentation fault (core dumped)

On macOS 10.12.6, the crash report dialog appears with the following details:

Process:               DomesdayDuplicator [16003]
Path:                  /Users/USER/*/DomesdayDuplicator.app/Contents/MacOS/DomesdayDuplicator
Identifier:            Test.DomesdayDuplicator
Version:               0
Code Type:             X86-64 (Native)
Parent Process:        ??? [1]
Responsible:           DomesdayDuplicator [16003]
User ID:               501

Date/Time:             2018-09-23 18:46:24.940 -0400
OS Version:            Mac OS X 10.12.6 (16G1510)
Report Version:        12
Anonymous UUID:        751163B1-9535-E8F1-5662-AD7C970E78F0

Sleep/Wake UUID:       1E52CB42-B772-4EC3-AF1B-D09528B95E65

Time Awake Since Boot: 190000 seconds
Time Since Wake:       20000 seconds

System Integrity Protection: enabled

**Crashed Thread:        1  PlayerControl**

Exception Type:        EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:       KERN_INVALID_ADDRESS at 0xffff9f810dfd4b75
Exception Note:        EXC_CORPSE_NOTIFY

Termination Signal:    Segmentation fault: 11
Termination Reason:    Namespace SIGNAL, Code 0xb
Terminating Process:   exc handler [0]

VM Regions Near 0xffff9f810dfd4b75:
--> shared memory          00007ffffff32000-00007ffffff33000 [    4K] r-x/r-x SM=SHM  
    

Thread 0:: Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib        	0x00007fffd6bf634a mach_msg_trap + 10
1   libsystem_kernel.dylib        	0x00007fffd6bf5797 mach_msg + 55
2   com.apple.CoreFoundation      	0x00007fffc0efe874 __CFRunLoopServiceMachPort + 212
3   com.apple.CoreFoundation      	0x00007fffc0efdcf1 __CFRunLoopRun + 1361
4   com.apple.CoreFoundation      	0x00007fffc0efd544 CFRunLoopRunSpecific + 420
5   com.apple.HIToolbox           	0x00007fffc045cebc RunCurrentEventLoopInMode + 240
6   com.apple.HIToolbox           	0x00007fffc045ccf1 ReceiveNextEventCommon + 432
7   com.apple.HIToolbox           	0x00007fffc045cb26 _BlockUntilNextEventMatchingListInModeWithFilter + 71
8   com.apple.AppKit              	0x00007fffbe9f3a54 _DPSNextEvent + 1120
9   com.apple.AppKit              	0x00007fffbf16f7ee -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 2796
10  com.apple.AppKit              	0x00007fffbe9e83db -[NSApplication run] + 926
11  libqcocoa.dylib               	0x0000000110c93e0d 0x110c69000 + 175629
12  org.qt-project.QtCore         	0x000000010eed7d3e QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) + 398
13  org.qt-project.QtCore         	0x000000010eedc8b1 QCoreApplication::exec() + 369
14  Test.DomesdayDuplicator       	0x000000010e1c4416 main + 70
15  libdyld.dylib                 	0x00007fffd6acf235 start + 1

Thread 1 Crashed:: PlayerControl
0   Test.DomesdayDuplicator       	0x000000010e1e0b33 PlayerCommunication::disconnect() + 99
1   Test.DomesdayDuplicator       	0x000000010e1e4858 PlayerControl::run() + 536
2   org.qt-project.QtCore         	0x000000010ed2caae 0x10ecff000 + 187054
3   libsystem_pthread.dylib       	0x00007fffd6ce893b _pthread_body + 180
4   libsystem_pthread.dylib       	0x00007fffd6ce8887 _pthread_start + 286
5   libsystem_pthread.dylib       	0x00007fffd6ce808d thread_start + 13

Thread 2:: org.libusb.device-hotplug
0   libsystem_kernel.dylib        	0x00007fffd6bf634a mach_msg_trap + 10
1   libsystem_kernel.dylib        	0x00007fffd6bf5797 mach_msg + 55
2   com.apple.CoreFoundation      	0x00007fffc0efe874 __CFRunLoopServiceMachPort + 212
3   com.apple.CoreFoundation      	0x00007fffc0efdcf1 __CFRunLoopRun + 1361
4   com.apple.CoreFoundation      	0x00007fffc0efd544 CFRunLoopRunSpecific + 420
5   com.apple.CoreFoundation      	0x00007fffc0f3cd31 CFRunLoopRun + 97
6   libusb-1.0.0.dylib            	0x000000010e23b208 darwin_event_thread_main + 398
7   libsystem_pthread.dylib       	0x00007fffd6ce893b _pthread_body + 180
8   libsystem_pthread.dylib       	0x00007fffd6ce8887 _pthread_start + 286
9   libsystem_pthread.dylib       	0x00007fffd6ce808d thread_start + 13

Thread 3:: UsbDevice
0   libsystem_kernel.dylib        	0x00007fffd6bff19e poll + 10
1   libusb-1.0.0.dylib            	0x000000010e237546 handle_events + 475
2   libusb-1.0.0.dylib            	0x000000010e237104 libusb_handle_events_timeout_completed + 259
3   Test.DomesdayDuplicator       	0x000000010e1cb17c UsbDevice::run() + 220
4   org.qt-project.QtCore         	0x000000010ed2caae 0x10ecff000 + 187054
5   libsystem_pthread.dylib       	0x00007fffd6ce893b _pthread_body + 180
6   libsystem_pthread.dylib       	0x00007fffd6ce8887 _pthread_start + 286
7   libsystem_pthread.dylib       	0x00007fffd6ce808d thread_start + 13

Thread 4:: com.apple.NSEventThread
0   libsystem_kernel.dylib        	0x00007fffd6bf634a mach_msg_trap + 10
1   libsystem_kernel.dylib        	0x00007fffd6bf5797 mach_msg + 55
2   com.apple.CoreFoundation      	0x00007fffc0efe874 __CFRunLoopServiceMachPort + 212
3   com.apple.CoreFoundation      	0x00007fffc0efdcf1 __CFRunLoopRun + 1361
4   com.apple.CoreFoundation      	0x00007fffc0efd544 CFRunLoopRunSpecific + 420
5   com.apple.AppKit              	0x00007fffbeb40f02 _NSEventThread + 205
6   libsystem_pthread.dylib       	0x00007fffd6ce893b _pthread_body + 180
7   libsystem_pthread.dylib       	0x00007fffd6ce8887 _pthread_start + 286
8   libsystem_pthread.dylib       	0x00007fffd6ce808d thread_start + 13

Thread 5:
0   libsystem_pthread.dylib       	0x00007fffd6ce8070 start_wqthread + 0
1   ???                           	0xd0e0001100617461 0 + 15051030027693028449

Thread 6:
0   libsystem_kernel.dylib        	0x00007fffd6bfe44e __workq_kernreturn + 10
1   libsystem_pthread.dylib       	0x00007fffd6ce8621 _pthread_wqthread + 1426
2   libsystem_pthread.dylib       	0x00007fffd6ce807d start_wqthread + 13

Thread 7:
0   libsystem_kernel.dylib        	0x00007fffd6bfe44e __workq_kernreturn + 10
1   libsystem_pthread.dylib       	0x00007fffd6ce8621 _pthread_wqthread + 1426
2   libsystem_pthread.dylib       	0x00007fffd6ce807d start_wqthread + 13

Thread 8:
0   libsystem_kernel.dylib        	0x00007fffd6bfe44e __workq_kernreturn + 10
1   libsystem_pthread.dylib       	0x00007fffd6ce8621 _pthread_wqthread + 1426
2   libsystem_pthread.dylib       	0x00007fffd6ce807d start_wqthread + 13

Thread 9:
0   libsystem_kernel.dylib        	0x00007fffd6bfe44e __workq_kernreturn + 10
1   libsystem_pthread.dylib       	0x00007fffd6ce8621 _pthread_wqthread + 1426
2   libsystem_pthread.dylib       	0x00007fffd6ce807d start_wqthread + 13

Thread 10:
0   libsystem_kernel.dylib        	0x00007fffd6bfe44e __workq_kernreturn + 10
1   libsystem_pthread.dylib       	0x00007fffd6ce8621 _pthread_wqthread + 1426
2   libsystem_pthread.dylib       	0x00007fffd6ce807d start_wqthread + 13

Thread 11:
0   libsystem_kernel.dylib        	0x00007fffd6bfe44e __workq_kernreturn + 10
1   libsystem_pthread.dylib       	0x00007fffd6ce8621 _pthread_wqthread + 1426
2   libsystem_pthread.dylib       	0x00007fffd6ce807d start_wqthread + 13

Thread 12:
0   libsystem_pthread.dylib       	0x00007fffd6ce8070 start_wqthread + 0

Thread 1 crashed with X86 Thread State (64-bit):
  rax: 0x000061000088fa50  rbx: 0x000070000de4fd98  rcx: 0x000000000001d25a  rdx: 0x000000000001d259
  rdi: 0xffff9f810dfd4b75  rsi: 0x0000000000000008  rbp: 0x000070000de4fdb0  rsp: 0x000070000de4fd70
   r8: 0x0000000000000040   r9: 0x00007fffdfa2a040  r10: 0xffffffffffffffff  r11: 0x0000000000012068
  r12: 0x00006080000f9f80  r13: 0x000000010e1f871b  r14: 0x00006080002235a0  r15: 0x000070000de4fdc4
  rip: 0x000000010e1e0b33  rfl: 0x0000000000010246  cr2: 0xffff9f810dfd4b75
  
Logical CPU:     4
Error Code:      0x00000004
Trap Number:     14


Binary Images:
       0x10e1c0000 -        0x10e209ff3 +Test.DomesdayDuplicator (0) <EA953DE1-D00E-3CC1-9B53-7ED9D7142316> /Users/USER/*/DomesdayDuplicator.app/Contents/MacOS/DomesdayDuplicator
       0x10e230000 -        0x10e23fff7 +libusb-1.0.0.dylib (0) <3E5346AD-C17E-3498-AFFD-16E86AB1FABE> /usr/local/opt/libusb/lib/libusb-1.0.0.dylib
       0x10e24b000 -        0x10e67cffb +org.qt-project.QtWidgets (5.11 - 5.11.2) <C185DF88-512A-32E3-BD7C-89CEE4471559> /usr/local/opt/qt/lib/QtWidgets.framework/Versions/5/QtWidgets
       0x10e7df000 -        0x10ebfdfff +org.qt-project.QtGui (5.11 - 5.11.2) <1849A311-0E9F-3426-8FA8-3FD7498D5A2A> /usr/local/opt/qt/lib/QtGui.framework/Versions/5/QtGui
       0x10ecff000 -        0x10f1eafff +org.qt-project.QtCore (5.11 - 5.11.2) <5C352421-62AD-38CD-8FE6-19717EB0F1C7> /usr/local/opt/qt/lib/QtCore.framework/Versions/5/QtCore
       0x10f2a1000 -        0x10f2adff3 +org.qt-project.QtSerialPort (5.11 - 5.11.2) <BE256056-08A0-331F-9482-EC18D176C1ED> /usr/local/opt/qt/lib/QtSerialPort.framework/Versions/5/QtSerialPort
       0x110c69000 -        0x110dc1fff +libqcocoa.dylib (0) <68770516-E626-30D3-8E98-ABFCBE851DB4> /usr/local/Cellar/qt/5.11.2/plugins/platforms/libqcocoa.dylib
       0x110e08000 -        0x110e68ff3 +org.qt-project.QtDBus (5.11 - 5.11.2) <4189B29B-C84B-3B3B-910B-F0B8DE46FF6F> /usr/local/Cellar/qt/5.11.2/lib/QtDBus.framework/Versions/5/QtDBus
       0x110e81000 -        0x110eabff3 +org.qt-project.QtPrintSupport (5.11 - 5.11.2) <8C8214B5-D252-362B-AD59-2F80135CA4B9> /usr/local/Cellar/qt/5.11.2/lib/QtPrintSupport.framework/Versions/5/QtPrintSupport
       0x113100000 -        0x113106ff3 +libqgif.dylib (0) <A8AB70E2-611B-30C6-8290-BE4BD1BFF96C> /usr/local/Cellar/qt/5.11.2/plugins/imageformats/libqgif.dylib
       0x113566000 -        0x11356dfff +libqicns.dylib (0) <FDBA40D8-47A0-3028-AF73-0168914D4E0B> /usr/local/Cellar/qt/5.11.2/plugins/imageformats/libqicns.dylib
       0x113572000 -        0x113576fff +libqmacheif.dylib (0) <139CBA45-2765-3D01-8BE7-FDEB15CB511C> /usr/local/Cellar/qt/5.11.2/plugins/imageformats/libqmacheif.dylib
       0x1135a4000 -        0x113616ff7  com.apple.driver.AppleIntelHD4000GraphicsMTLDriver (10.25.19 - 10.2.5) <FF32F5EE-5F13-3D51-BF43-C061F30A1880> /System/Library/Extensions/AppleIntelHD4000GraphicsMTLDriver.bundle/Contents/MacOS/AppleIntelHD4000GraphicsMTLDriver
...

The Duplicator GUI or the FX3 should not connect or show an error if the capture device is connected to a USB2 port.

The Linux host software currently sends USB configuration commands as the options are selected in the GUI. Under normal operation this functions without issue. However, when developing, modification to the FPGA or FX3 code can cause the device to reset the options and become out of sync with the GUI.

It would be better to send all configurations again at the start of a capture to ensure the device is always configured as per the GUI.

Starting a 16-bit capture works fine but stopping capture seems to hang and requires a Control-C to exit:

UsbCapture::run(): Setting up the transfers
UsbCapture::allocateDiskBuffers(): Allocating memory for disk buffers
UsbCapture::run(): Submitting the transfers
UsbCapture::runDiskBuffers(): Thread started
UsbCapture::run(): 16 simultaneous transfers launched.
PlayerControl::stopAutomaticCapture(): Automatic capture not running, ignored.
UsbDevice::sendVendorSpecificCommand(): USB interface claim failed (connected via USB2?) with error: LIBUSB_ERROR_BUSY
UsbCapture::run(): Transfer stopping - waiting for in-flight transfers to complete...
UsbCapture::run(): Transfer stopping - Freeing transfer buffers...
UsbCapture::run(): Transfer stopping - waiting for disk buffer processing to complete...
UsbCapture::runDiskBuffers(): Thread stopped
^C

Preferences seem to get lost (ie it reverts back to 10-bit capture mode when I restart the app).

The installation of the ezUSB Cypress environment is a minefield of awful.

It should be possible to generate a makefile to compile the firmware from the command line and simplify the build requirements. There is also a reference to Gpif2Usb in the .CPROJECT file for Eclipse that shouldn't be in there - this needs to be removed as it can confuse the project import to Eclipse.

Use different file extensions for the two different formats of file

Right now the Duplicator firmware provides a maximum sample rate of 35MSPS for PAL. The idea is to keep the sample rate at 8x the FSC in order to make the decoding mathematics simpler. However, theoretically the sampling rate should not affect the decoding (if the decoding software is made agnostic of the sampling rate). For the highest possible quality of capture the duplicator should sample as fast as possible, this should be added as a capture option in the GUI (and implemented in the FX3 and FPGA firmware).

At the moment the duplicator samples at 32 MSPS using a single fixed PLL in the FPGA Verilog code to generate the sampling clock to the ADC chip.

From a mathematical point of view it makes sense to have the sampling clock running at a multiple of the FSC (the colour burst frequency); these are as follows:

• 3.57954 MHz for NTSC
• 4.43361875 MHz for PAL

Based on this (and the ADC limit of 40MSPS) it would be optimum to sample NTSC at 8xFSC = 28.63632 MSPS and PAL at 8xFSC = 35.46895 MSPS.

The Verilog code should be enhanced to support two PLLs selectable via a control signal from the FX3 USB board. The USB board should provide a vendor-specific USB command to select the required frequency based on the desired video standard being sampled.

An accurate maths model of the RF front-end (including the effect of the input impedance) would help when selecting the right gain values for the RF amplifier. Right now the OPA690 datasheet gives the settings for the opamp gain, but doesn't include any impact from the 100 Ohm impedance on the input to the board (meaning the predicted mV output from the RF stage is generally lower than the calculation suggests).

For network shares the OS may report zero space available (when the storage space is unknown).

The GUI application shows this is '00:00:00' - perhaps 'unknown' would be a more useful feedback to the user?

Testing (by decoding the RF sample using ld-decode) has shown an issue with the current low-pass filter design.

On NTSC CAV discs the white output is at 9.35MHz which causes a harmonic at 28.05MHz. This harmonic is aliased into the captured signal at 11.95MHz when capturing at 40MSPS.

The aliasing causes distortion of the video signal after around frame 40,000 of a NTSC CAV disc and causes signal degradation which is particularly bad at frames 50,000 and beyond. Reproduction of the issue requires a 12" test disc (which are difficult to source), so this was not see in the initial testing of the 2_2 board.

There are three possible solutions so far:

1. Modify the current LPF to provide a lower-frequency stop-band
2. Increase the sampling rate to capture the harmonic
3. Redesign the filter to be active (i.e. increase the 'drop-off' effect of the filter to remove the harmonic from the sampled signal)

(1) is the simplest solution, but has the side-effect of attenuating the 'good' signal too much making decoding more difficult

(2) is practical, but requires a more expensive ADC (sampling would need to be 60MSPS). This is really just 'masking' the issue at the cost of higher sampling rates (and generation of unnecessary large RF samples)

(3) is probably the correct long-term fix - but requires a redesign of the duplicator board

This isn't a pronounced issue on the 2_2 board (however the 2_0 board suffers badly at 40MSPS and can cause clipping - but (I believe) there is only 1 2_0 board in the wild, so it's not a big issue).

For the next revision of the PCB this should be examined again. It's possible that using a voltage-following opamp configuration to generate the DC offset reference could improve this further.

The decoding process isn't sensitive to the DC offset, so this is not a high-priority issue - it would be nice to finally solve it completely though :)

The input impedance of the Domesday Duplicator 2_2 PCB is not correct and is causing unwanted attenuation of the signal. The nominal impedance of the LaserDisc player should be 47-50 ohms; and the duplicator should closely match this. This requires the very first component after the BNC connector to be a 47-50R resistor connected to ground immediately before the decoupling capacitor C1.

Note: this doesn't seem to have a noticeable impact on the 2_2 board's performance; but it does make predicting the gain levels difficult.

Options for auto-capture and player remote control should be unavailable if a RS232 player is not connected

Since the output from the ADC is 10 bit, it would be nice to have the option of saving the Duplicator output in a 'packed' format to save disc space (rather than just 16-bit signed data).

Add user feedback for the amount of time elapsed on the current capture.
Possible to set auto stop time as max length of discs is ~70 mins.

Currently there is no way to verify that no data was lost or corrupted during capture. This could be addressed by having the FPGA add some form of block headers containing index numbers, along with a checksum at the end of the block.

If the blocks are not synchronized so they appear at specific positions in the data, a 'magic number' could precede the block header, so it can be found regardless of position.

There is currently no option to enable physical panel key locking when performing an automatic capture

It would be nice (given the size of the LaserDisc captures) if the Duplicator GUI could monitor the available free-space on the target hard drive when capturing and provide a summary of how many discs can be stored (at the present capture settings).

There is an edge-case when capturing discs automatically using PIC. Some discs (like the GGV1069) have a pause command included in a frame; this may cause the player to pause during PIC and the capture state-machine doesn't deal with this (potentially continuing forever recording the paused frame).

Currently the Duplicator application is only compatible with Ubuntu/Linux. It should be possible (using QT) to make the capture application cross-platform.

The Linux front-end application provides automated capture of a laserdisc including lead-in by beginning sampling before the disc is spun up. When the disc hits the last frame the player pauses. It's questionable if there is lead-out information which isn't seen at the end of the sample.

Testing in normal capture mode would continue sampling after the disc ends. Captures should be made in both modes and compared to see if this is a potential issue (as a normal capture wouldn't be affected).

It would speed installation if a pre-compiled flash image was available for the FX3 - at the moment the user must install the (cypress custom) version of Eclipse and compile the image, which is an unnecessary pain.

It'd be a bit quicker and easier on the player, but no biggie. I can see why one would want to try to get the lead in though.

The start/stop capture USB command is a left-over from a previous implementation of the FPGA buffering code and doesn't really serve a purpose any more. It should be removed from the code-base in order to keep things simple.

It would be good if it was possible to override the automatic file name creation if required and add some form of unique identification to the file.

Text is difficult to read when macOS 10.14 is set to its dark theme. Perhaps this will be addressed by Qt; if not, I suggest changing either background or text color.

Test case:

1. Start a capture
2. Do stuff on the computer that causes disk writes to slow down, such as copying other files on the same drive

The capture will halt due to buffer overflow. Messages appear in the console, but nothing appears in the GUI. The timer continues to count up, though the file size does not.

Clicking to stop transfer has no effect, and clicking it again causes the app to stop responding.

Suggested behavior:
Add some sort of notification/pop-up that indicates capture has failed, and reset to idle state.

I think I didn't update my DD board correctly, as it captures in test mode @ 60MB/sec in both NTSC and PAL modes regardless of other settings. It would be nice for the system to have version checks on both FPGA and FX3 programs to ensure upgrades are made correctly. (thanks!)

Since the Duplicator now has variable gain, it would be useful to be able to monitor the amplitude of the RF capture in real-time from the GUI.

Many PCB fab providers have a limit of 100mm length after which boards become more expensive to produce. The current 2_0 board revision exceeds this by 5mm.

The revision 2_0 board was designed for prototyping work and has fairly wide tolerances. When redesigning for issue #1 the board size should also be reduced if possible. There is also clearance under the board to flip the BNC socket to the lower copper layer which should generate additional board space.

I got PIC (which is quite nifty!) working with my V2800 using this info: Player ID is P153701, and 4800bps is a possible baud rate which I had to hack the GUI for (the dip switch can be set for 9600, but there's a parameter setting I remember using for which 4800 is the limit)

Right now the player integrated options are available when no player is connected.

I received some feedback that the duplicator GUI does not run correctly outside of the QT Creator environment (i.e. compiled directly using qmake). The GUI project should be updated with both debug and release versions and tested in an Ubuntu 16.04 LTS environment.

I'll mark this as a bug for now and verify that this is actually an issue and not a local environment issue since there is no technical information provided about the observation.

When connecting to a LVDP via serial, the application does not show any GUI message indicating if the connection was unsuccessful. The 'Player Integrated Capture' dialogue simply remains greyed-out

Selecting test mode when USB device is disconnected causes the application to crash as it attempts to send a vendor specific command to a non-existent device.

The DC offset of the RF signal is provided by the ADS825’s internal reference generator which is routed through two 1.62Kohm precision resistors to create the common-mode voltage which should be in the exact centre of the ADC’s signal range. Testing against the revision 2_0 version of the board gave the following results:

• REFT = 3489mV
• REFB = 1509mV
• IN = 2491mV

With REFT-REFB = 1980mV the value at IN (with no input) should be (REFT-REFB) / 2 = 990mV above REFB, i.e. 2499mV. The value of IN under test was 2491mV which is within the expected range given the 1% tolerance of the precision resistors.

The ADC uses the not IN pin to act as the common-mode reference for the ADC process (when the ADS825 is used in a single-ended configuration). The ADS825 recommended configuration is to connect the CM output pin to not IN (with decoupling) to present the correct common-mode voltage for conversion (and this is the implementation on the revision 2_0 board). However, testing of the 2_0 board shows the CM pin provides a voltage of 2370mV; this is 129mV under the true common-mode voltage presented by REFT and REFB and causes the 2_0 revision board to read a positive DC-offset when sampling the inbound signal. This extra offset reduces the sensitivity of the ADC by 129mV on the positive-side of the incoming signal reducing the effective ADC range to 1851mV peak-to-peak.

Currently this unwanted offset is corrected by the FPGA software and care should be given not to exceed the reduced 1851mV peak-to-peak range.

A possible fix could be the addition of two more 1.62Kohm resistors on REFT and REFB used to generate the common-mode offset from the same source as the signal biasing and the CM should be simply decoupled to ground. This may receive interference from the RF front-end though, so needs to be tested.

At the moment the PIC feature can only support a couple of specific Philips players - it would be nice if the actual command set used over RS232 was abstracted from the state-machine in a layered fashion to allow the insertion of different commands for different players. This could even be done via a configuration allowing users to configure the PIC feature for their own player.

Since the PIC feature can determine the length of a CAV or CLV disc, it would be useful if there was a simple option just to capture the whole disc using PIC.

To reproduce the issue.

Open the DomesdayDuplicator application
Turn Edit > Test Mode to On.
Capture a few seconds (More than one)
Exit application
open application again (App defaults to test mode off but does not tell the FPGA its now off)
capture for a few seconds again.
close application

Open laserdisc analyser
Test the first file generated (Expected test data) and verifies OK.
Test the second file generated (Expected real data) and verifies OK and should fail.

Some labels/captions in the UI are being clipped, with somewhat different cicrumstances in both Ubuntu and macOS.

I am not aware of any special display or scaling settings on my ubuntu setup, though it is running in a VM. The Mac is an early 2013 Retina MacBook Pro with "best for retina" scaling option.

The ADS828 is a pin-compatible 75MSPS version of the ADS825. Potentially the chip could be substituted in the hardware to increase the maximum possible sampling speed. This could lead to other (adverse) knock on effects; the dual-clock FIFO in the FPGA may not be able to keep up, the DE0-Nano pin headers are only rated for 64MHz and the USB bandwidth requirements would double (probably more than the FX3 can handle). Probably worth experimenting with though to analyse the potential.

Some CAV boxsets have more than 4 sides.

I have seen 6 side boxset with extras but there may be one or more with 7+

With a serial connected player it should be possible to auto detect CAV/CLV PAL/NTSC and disc side A/B along with user code using Philips F-Codes (Unsure if available from Pioneer / Sony serial comms)