Page 15 of 18

PostPosted: Tue Jan 15, 2013 6:53 pm
by Viewmaster
The reset propagation time of the 4060 is 210 nsec with 15v working and the prop time to Q1 is also 210 nsec on Fairchild's write up on the 4060.
Interstage delay is 125nsec so total looks to be around the 1usec mark.

PostPosted: Tue Jan 15, 2013 7:21 pm
by Steve Anderson
Viewmaster wrote:Thank gawd all that tedious soldering is over.......I never wish to see another soldering iron in my life.

But, you know you will...

I don't think there will be any problem with the oscillator re-start time, we'll see. If a shorter pulse than the original syncs were generated that should fix things. Play it by ear...

Steve A.

PostPosted: Wed Jan 16, 2013 9:15 pm
by Viewmaster
Steve Anderson wrote:I don't think there will be any problem with the oscillator re-start time, we'll see. If a shorter pulse than the original syncs were generated that should fix things. Play it by ear...
Steve A.

I tried linking the reset to the line pulses but the picture slide sideways at an angle. So, as you say, the xtal osc must be reset early just before the line pulse has ended.
I will make an addition to your cct as shown soon to give a very short xtal osc reset pulse. (the 50u sec time to be variable.)

Incidentally, in connecting and disconnecting and pulling around the boards a tiny whisker of solder shorted pins 10 and 11 of the 125 u sec master reset timer (the frame pulse) .
This caused the picture to slowly drift sideways. All OK now, but it neatly illustrates how essential that 32nd master reset pulse is that your cct generates. The variable pot moves the picture frame up and down very smoothly to enable correct framing to be retained.

I might also try a small trimmer in the xtal osc cct. just to see if that cures the bounce too.

Also I think a transistor is on the blink and /or some IDC connectors are dodgy as I have lost some vert and hor lines, and one line is partly on all the time. At least I now have solved the problem of the missing last 7 lines out of the 32........
It was a missing connection on the last 4017 on the 32 line cascade inhibit pin that should have been earthed.

All small teething troubles just like the Dream Liner aircraft. :)
At least I don't have any smoke in my cockpit from the battery pack :shock:

PostPosted: Wed Jan 16, 2013 9:37 pm
by Steve Anderson
Well, I'm a bit surprised that the oscillator start-up time is so long...this is different to the logic propagation delays mentioned in the datasheets...and is conveniently omitted. I would have expected a few microseconds at nearly 5MHz, but then this logic family is so damn slow, even at 12V, it comes as no surprise.

Try 50us and see what happens, if it works try reducing it until it goes wobbly again and then aim for double that value.

If it doesn't work a brain-storming session may be in order...

Steve A.

PostPosted: Thu Jan 17, 2013 5:42 am
by Viewmaster
I am beginning to wonder if I am on the right tack.....this afternoon I knocked up a 555 astable with both course and fine control pots.
I was able to run at 19.2kHz with slight drift over 20 minutes or so.
By changing the timing I could make the picture drift either way depending on whether correct 19.2 was slightly higher or lower in freq.
This made no difference to the vertical oscillation bumping or its timing or the amount of it.

Even running at half speed or twice speed where the picture was either very much expanded or compressed made no difference to the 3 Hz oscillation rate either. :shock:

So tentatively I conclude that it is not the line start up pixel clocking oscillator timing but something else, as I would have thought that the above would have resulted in quite a change in the 3Hz bumping.

I shall use Gary's application tomorrow to record a short NBTV video to see if that is different in any way from the club CD....grasping at straws maybe, but then I have plenty of straws left over from
the LED masking. :)

Maybe if I greatly shortened the line pulse length it might help?
Or maybe there is a subtle wiring fault in my 48 pixel 4017 cascade ?
SoI must check all this out.

It's all Maybe's and Or's at present in this new ball game :lol:

PostPosted: Thu Jan 17, 2013 10:18 am
by gary
Albert, which club CD? That's important because the first disk has a slight temporal issue - but that should only cause the picture to very slowly scroll up or down.

Is there any way you could post a short clip of the phenomenon? It may jog something in this ageing brain of mine or someone else's for that matter ;-)

BTW you are not yet processing syncs are you? (I mean in the sense of locking the picture).

A method for determining whether the CD player output has issues is to plug it into your PC and use TBP with sync processing turned off - if the picture remains stable it's fine if not - well you should see something akin to what you are seeing on the niptrix. It would be even better if you could connect it via s/pdif.

PostPosted: Thu Jan 17, 2013 10:32 am
by gary
Viewmaster wrote:Baird's commutator on his lamp display would not have allowed this to be done, so maybe it has never been seen on NBTV before. :shock:

Only if you excluded software based NBTV Televisors... 8)

PostPosted: Thu Jan 17, 2013 2:32 pm
by Steve Anderson
Albert, how are you doing the actual sync-slicing/separation? If there's a trace of hum in there this could cause a symptom like this. It could be 50Hz hum - direct mains pickup, or 100Hz hum from a power supply problem.

Perhaps temporarily relocating the power transformer some distance away from the electronics may give a clue. If you have access to a 12V lead-acid battery try that too.

Also consider one of your favorite subjects, earth/ground returns.

Steve A.

PostPosted: Thu Jan 17, 2013 6:36 pm
by Viewmaster
Gary I have two club CDs of the test figures. They have never given me trouble before. Both give the 3Hz bounce.
I also used your application last night to make a short NBTV video and that bounces too. so it's not the CDs.

The line sync is obtained from the clubs cct using a single CA3240 (page 13 of handbook). Pulses look good and stable on the 'scope.

Steve, I will do as you say, running it all on a battery as power drain is small.

But I now believe that the fault is somewhere in the cct of the 48 pixel 4017 cascade line.
In addition to the resetting which is in built into the cct I also have introduced the extra master reset to ensure correct start of each frame.

This is also used in the 32 line cascade cct too BTW and this seems to be stable so the basic circuit seems sound.

Also I will carefully time this 3Hz frequency to see if it is related in any way to the 12 1/2 per sec frame freq. That might be an important clue.

So, thanks both of you for help and suggestions but I will now go through the pixel 4017 cascade board with a fine tooth comb to see if I can find a wiring error etc. and let you know what I find. Also experiment with the master resetting cct.
If I cannot solve it I shall rename the Niptrix,
" The Bouncy Castle Niptrix." :lol:

PostPosted: Thu Jan 17, 2013 7:16 pm
by gary
Oh if you ARE using syncs then I think there is a good that you sync slice is too near the top of the pulse - have you tried lowering it? Don't forget the CDs are 44.1kHz and thus the sync pulses are heavily low pass filtered so the leading edge of the pulse may not be exactly the same over 4 lines.

But you can eliminate that by temporarily removing the sync processing - let the system free wheel at the 19.2kHz the picture may not be framed but it *should* be stable.

Also to try - are you using Video2NBTV V2 alpha? - if not that would remove the heavy lowpass filtering needed for 44.1kHz as it creates 48kHz video.

PostPosted: Thu Jan 17, 2013 9:02 pm
by gary
Oh, and running it on batteries is one of my favourite debugging strategies.

PostPosted: Thu Jan 17, 2013 9:30 pm
by Steve Anderson
gary wrote:Oh, and running it on batteries is one of my favourite debugging strategies.

Indeed, I have two 12V 7Ah Lead-Acid batteries in my ...err, workshop/office for that reason. They also act as spares for the UPS. I can 'burn-in' either/both software or hardware while I snooze yet the whole area is effectively dead (and safe) for others who may wander in and pick something up which they might otherwise later regret.

Running things off batteries will eliminate/identify hum problems but not earth/ground issues or poor bypassing/decoupling of of my "hot buttons" as you know.

Steve A.

PostPosted: Thu Jan 17, 2013 9:54 pm
by gary
Yes, especially for digital circuits (all those square waves tch). I suppose I don't think of that as a debugging strategy as adding bypass capacitors etc. to me is as routine as brushing my teeth (and yes they are all still my own - and all the important ones are still there ;-)) - so I see that as a mandatory design and implementation procedure, HOWEVER, EMI of any sort tends to be more of an art than a science so even if you do the right thing there is no guarantee - that's when you have a case of the horrors - thankfully it is relatively rare if you follow good practices.

One thing in my life I regret is the fact that during my degree I made a connection between my thermodynamics class and my field theory class that led me to believe that a finite element analysis of a PCB could lead to greatly simplifying at least some EMI problems - I had intended to do it as my thesis but got talked into doing a relatively mundane thing for my employer. Oh well.

But I digress... again...

Back to the topic though - there is no real evidence to suggest the problem is related to EMI (noise) - it could be a race condition, or any any manner of other things. A careful analysis of the waveforms may be required - but I would really like to see the symptoms... ;-)

PostPosted: Fri Jan 18, 2013 12:21 am
by Steve Anderson
I know I keep banging on about this, but layout, bypassing and decoupling of supplies is essential to a rewarding result.

Attached are two photos of something I'm working on for NBTV at the moment of which the details I'm not going to reveal at this point.

Layout 1. jpg is how I originally conceived the grounds and supplies. Green is earth/ground/0V, orange +3.3V for all the logic, red +12V, and blue -12V for all the analogue parts. This will be shrunk into fewer and smaller parts in due course. The final board should be half the size of this example.

You'll note that I have bypassed the supply to the main micro chip via a 100nF cap right under its socket. This thing is running at 64MHz on far not a hiccup. It can be done.

As it has evolved it looks like "Interim Mess 1.jpg", but most of the hardware is defined now, from here on in it's primarily a software exercise.

But note the multiple earth links, the amount of decoupling and bypassing, and the compact layout. No sprawling real-estate here!!

Steve A.

PostPosted: Fri Jan 18, 2013 7:37 pm
by Viewmaster
Well guys I will try it on batteries alone, but at present I have the boards disconnected to examine all the wiring.

I do have decoupling on the power line on all ICs on the cascade clocking ccts. but will look at this again.

I'll try not to run it all at 64mHz Steve. :wink:

One important error I have found is that although the 32 line cascade cct clocking is reset at every frame, which is correct, the 48 pixel cascade clocking is also reset by the same frame pulse.
...........This is wrong !!
The 48 pixel cascade cct should be reset every line.
So I will correct this and also put in preset pots to enable me to change all the lengths of all the sync pulses............
A 125u sec long pulse at present resetting the pixel pulses, which at 19.2kHz, are only about 50u sec long seems wrong too, so changing all the lengths may show up a change in the bouncing time, or even its elimination.
Going on from what Gary said, by changing sync pulse length this will sharpen then up too, so this might remove another cause of the problem.

So plenty of investigative work to be done as the snow comes down
here in the UK Midlands :) Brrrrrrr.