Do you think it would it be viable to add the two extra resistors to the existing 2.0 pcb? I could cut traces if need be and tack them on with some hot glue and wrapping wire. Have any connections between components changed apart from the addition of these resistors, or is the rest just cosmetic and physical layout/routing changes?

It's not that simple to alter the previous board revision as the generation of the DC offset is done using a different method (and therefore uses other pins on the ADC that are not easily accessible on the old revision).

The new board also supports the 2_0 configuration too (but this is mainly for legacy board testing against new software builds).

Improvements are part of the nature of open-hardware projects (especially something like this which is on the 'bleeding-edge' of what's been done with LaserDiscs) - as more people get them there will be more people looking at the design, so there will always be an 'issue' of the occasional board update. You are an (appreciated!) early adopter I will try (if possible) to maintain backwards compatibility though - as I did in this new release.

Fair enough, I'll probably go ahead and build a 2.2 board then. Please don't worry about backwards compatibility if it in any way impacts your future design, especially on my account. I'd rather rebuild this device every 6 months than have the latest product be anything less than the best it can be. I ordered double of all high value parts when I built my board, and 5x the amount for all low value parts, so I've got everything on hand to assemble a new one. My only question to you before I order some new PCB's (which is only $5 for 10 now with the board shrink, thanks for that!), is do you anticipate another revision in the next couple of months, IE, do you have any other hardware changes in the works?

It's now at a point where, until the decoding is more advanced, it's difficult to see if anything needs improving - and most things in the RF path should be possible to alter by swapping existing passive component values (like the low-pass filter for example). The firmware and software will be the most likely point of change for the next coming months.

The board requires quite a time consuming testing cycle (I really could do with an RF spectrum analyser to speed things up - but they cost a lot of pizza!), so hardware stability is always better.

Good to hear; funny what shaving off a few millimetres can do, but keeping the cost down was one of the design aims - if you had to buy all of the FPGA and USB3 stuff on every iteration too it would be a little more painful Hopefully it demonstrates my thinking behind the 'stack it up' approach.

@simoni - Since my TBC software can (theoretically) work with data of any sample frequency, one thing I'm going to try soon is to modify the Domesday Duplicator firmware to generate a capture at a higher rate, to see if it makes a meaningful difference to the result. I should be able to get 40MHz out of the ADS825. One thing I'm strongly considering doing for my 2.2 board is substituting the ADS825 with the ASD828, to boost the maximum sample rate from 40MHz to 75MHz (IE, going to 11). There are other tasks I could use this board for, and the higher capture rate would help with this. According to the datasheets the two chips are pin compatible, but I notice the ADS825 claims a slightly higher SNR of 60dB, vs the 58dB of the ADS828. Could you take a look at the two chips and let me know if you think the ADS828 would work on your hardware, and if in your opinion the slightly different SNR would have any meaningful difference on the result?

@happycube - In order to decode the video and audio from a higher sample rate, I'd need to get lddecoder.py to be able to work with it. The only thing I'm not sure about modifying though are these constants:

These seem to be set to the values here for 28.636MHz, but .61 and 1.6 for 32MHz. Do they need to be adjusted in relation to the sample frequency somehow, and if so, what's the formula/process for picking appropriate values?

The ADS828 datasheet indicates that it is a drop-in replacement, so I don't think that will be an issue. However, there are a couple of other 'gotchas' that may be involved:

The dual-clock FIFO on the FPGA may not be able to take the strain of the increased sampling rate as you would be almost doubling the sustained throughput.

The DE0-Nano pin headers (IIRC) are rated for about 60MHz maximum signal speed. Right now that isn't an issue since the 'stacked' configuration keeps the signal runs to a minimum (and the sustained data rate is lower even if it bursts over the rated max).

The FX3 board may not be able to keep up; Doubling the Mbits/sec throughput is going to stress the USB3 connection a lot.

Don't get me wrong; I encourage you to try But you will probably find, given the resolution of the LD recording itself, that you just get a better sample of the noise as, with a single-ended configuration, I think the SNR will cause you to have exponential loss as you ramp up. For higher sampling rates a differential front-end would be better, but I abandoned the idea due to the cost and complexity verses the source resolution.

You have made me think that adding a 40MSPS sampling option to the software would be a good idea though, or perhaps 38MSPS (as running chips at the rated maximum is usually asking for problems )

@nemesis: Thanks! I think the 32mhz deemp settings are actually best for the Domesday Duplicator at any speed, but I'll have more on that eventually. .61 and 1.6 scale to much closer to the original LD spec, and I suspect the altered settings I homed in on dealt with the... imperfections... of using a video capture card for something it wasn't mean to do

My WAG is that the ADS825 and 828 are the same die, and at this late date they might not even bother to bin them and the only real difference is the price. I would try setting it to ~57.27mhz (16x FSC) and seeing if everything can take that.

_________________Happycube Labs: Where the past is being re-made, today. [meep!]

I just can't seem to nail colour decoding. I'm painfully close, but at the last step I'm doing something fundamentally wrong, and I can't figure out what. Here's a raw frame I currently obtain:I've written code to calculate the blanking level and IRE scale, lock onto the phase of the colour burst, and separate the Y, I, and Q components. If I discard the I and Q components and just decode Y (luma), I get a nice looking black and white image:So I must be doing a reasonable job of separating the I and Q signals. I just can't seem to process them properly. Here's what I'm currently getting:So yeah, not even close. No idea what I'm doing wrong here. Maybe with fresh eyes tomorrow I'll figure it out.

Looks like you don't have the TBC and/or burst phase lock quite correct. Focus on the color burst - it should be a steady green color.

Also for this bit of work capture color bars and work with that. Unfortunately my only attempt so far at capturing GGV1069 with the latest firmware was in DD's test mode and my V2800 is in the garage to get it's power switch hacked up/bypassed (or the power supply swapped... I found a broken late-2001 V2800 on eBay yesterday). Oops.

Side-note: There's a 1998 LD-V4400 and a June 2000(!) V8000 on eBay right now. They really did have a long production lifespan.

_________________Happycube Labs: Where the past is being re-made, today. [meep!]

I'm only working on NTSC decoding right now, so the PAL test cards aren't much help yet. I don't have any test card samples for an NTSC signal. I tried to capture a generated one from a test ROM for the Mega Drive via the composite video stream today, but I had trouble getting my test machine to cooperate. A straight composite signal isn't in the right range for the Domesday Duplicator analog input, and cdaxc kept on dropping samples randomly for some reason. It's worked before, so I'll have another try later. I should be able to get something usable out of it.

About a million bug fixes later though, and I have something that's vaguely in the region of viewable:What I'm discovering is that phase locking to the colour burst is hard! I underestimated just how sensitive it would be. The slightest variation and the hue goes off in perceivable ways, but from the RF the signal isn't even regular, and captures from consoles and other equipment I have which generates composite video shows they have their own problems and idiosyncrasies, from field timing that's off NTSC spec, to colour burst waves that look more like triangle or square waves, with length and position wildly varying. Analog receivers cope with them all though, so you can't just go by what the specs say, the software needs to at least be able to cope with anything an analog set could have thrown at it, because there's a kaleidoscope of "incorrect" signals out there that work anyway. I'm trying to write software which can adapt to all this, but writing something that's adaptive and tolerant of signals that are generated off-spec, while still pulling in imperfect signals which aren't regular back into conformity so the image is stable and correct, isn't an easy task. Underlying all this there's the loss of information problem, in that as soon as we quantized the analog waveform we approximated it, and even with good interpolation techniques, it's never quite as easy to derive precise, accurate information about the true frequency of a waveform, or the exact points at which it crosses certain thresholds, as it is to build an analog circuit which naturally derives that information in a precise, adaptive, and near perfect manner from the true analog waveform.

I can see I need to take a good look at the TBC issue again, and separate it clearly from framing. I need to first of all decide what the "correct" timing appears to be for the video stream, then use that information to perform TBC to force the input signal into conformity to that, but without distorting the hue mid-line by stretching or compressing the signal inappropriately. You've got a damn near perfect process working for that already happycube, but for a limited range of input signals. I'm going to have to spend some time planning an alternate approach here I think, which can achieve the same great result you've obtained, while making it more adaptive on the range of input signals it will accept. I might start by grafting in your existing comb filtering code into the back-end of my video decoder, so I can use a mature colour decoding process, and focus on making the input to it more flexible and adaptive. Once I've got that process getting a result on par with what you're currently achieving, but with a wider range of signal support, I can focus more on the colour decoding issue itself. Even without further work though, at that point I think it'll be up to task for a lot of things I'd like to use it for.

Nemesis> To try an make your life a little easier I've made a short (10MB) capture of the colour bar frames from the NTSC GGV1069 reference LaserDisc and uploaded it to the Domesday86 website. It's only a few frames, but it should be more than enough for you to run your testing against.

But as I originally posted early on in this topic, what is the end game here??Will there be some type of decoder for people to buy, is this going to get us regular LD collectors close to getting a new working player or is this just a hobbylike that Radio Shack thing I had when I was a kid to learn electronics??

Who is online

Users browsing this forum: No registered users and 2 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum