Missing sync pulse and the club standard --- Why?

Forum for discussion of narrow-bandwidth mechanical television

Moderators: Dave Moll, Andrew Davie, Steve Anderson

Postby AncientBrit » Wed Jun 20, 2007 12:36 am

Steve, re framing, that was the point I was making.

I "kick-off" with pixel 0, line 0 which is the start of a frame.
There is no other data preceeding this on the file.

2048 bytes later I assume a "frame flyback" and start painting again the pixels at 0,0.

I have no need to embed any framing info, it's implicit within the file format.

This of course will only work where the digital "channel" is not liable to interuption, or where the playback is fragmented.

BTW I can play back at any other frame by indexing a file pointer by n*2048 bytes and starting from the new reference.



Regards,


Graham
AncientBrit
Green padded cells are quite homely.
 
Posts: 858
Joined: Mon Mar 26, 2007 10:15 pm
Location: Billericay, UK

Postby AncientBrit » Wed Jun 20, 2007 12:42 am

A further thought.

If you really want to embed a digital sync pulse then peak white clip the signal at FEh.

Dedicate the value FFh to signify a frame sync flag.

The dynamic range is reduced by 1 in 255, not a great loss.

GL
AncientBrit
Green padded cells are quite homely.
 
Posts: 858
Joined: Mon Mar 26, 2007 10:15 pm
Location: Billericay, UK

Postby Andrew Davie » Wed Jun 20, 2007 12:56 am

AncientBrit wrote:A further thought.

If you really want to embed a digital sync pulse then peak white clip the signal at FEh.

Dedicate the value FFh to signify a frame sync flag.

The dynamic range is reduced by 1 in 255, not a great loss.

GL


If you're going digital, then it actually only needs to be a single bit in a single pixel, no? It could be the least significant bit, and have no discernable visual effect whatsoever.

But isn't the real challenge to embed the synching information in a signal that can be distorted by analogue transmission? Thus, a single value (or bit) is not appropriate; it has to be somehow encoded such that the signal will survive rather excessive distortion by the transmission medium.

I was wondering if the sound channel couldn't be used for the synching information? Sure, it's much 'nicer' keeping the video and synch together, but then again, keeping a 'clean' video signal, and moving the synchronisation/timing to a different channel also has appeal. For example, if the sound were NEVER allowed to have 0-value (and this could easily be achieved), then any 0-values would be considered synch pulses. They could be of short enough duration that they wouldn't be audible (I think), and yet they would probably not be distored so much by transmission that they would not be detectable.
User avatar
Andrew Davie
"Gomez!", "Oh Morticia."
 
Posts: 1590
Joined: Wed Jan 24, 2007 4:42 pm
Location: Queensland, Australia

Postby gary » Wed Jun 20, 2007 1:06 am

AncientBrit wrote:Steve, re framing, that was the point I was making.

I "kick-off" with pixel 0, line 0 which is the start of a frame.
There is no other data preceeding this on the file.

2048 bytes later I assume a "frame flyback" and start painting again the pixels at 0,0.

I have no need to embed any framing info, it's implicit within the file format.

This of course will only work where the digital "channel" is not liable to interuption, or where the playback is fragmented.

BTW I can play back at any other frame by indexing a file pointer by n*2048 bytes and starting from the new reference.



Regards,


Graham


Yes that is what I do with the colour wave file source option in NBTV The Big Picture! It is possible because the format is purely digital and so will not have timebase errors. The audio wave file (and CD) source option assumes that the input, whilst digital, could be the result of digitising analogue signals and therefore have all sorts of distortion, so it relies on there being strong line and frame synchronising for both sync and DC restoration. The other source, that of the soundcard, will definitely have lot's of distortion (especially with loss of DC, and usually timebase) and so really needs strong sync.
gary
 

Postby AncientBrit » Wed Jun 20, 2007 1:14 am

Andrew,

It can't be a single pixel because by definition you don't know the pixel before you have found it!.

So it could be any pixel and you have to dedicate the same mechanism to all.

If you use a single bit you lose 50% range (1/2).

If you set aside a single level you lose only 1 in 255.

GL
AncientBrit
Green padded cells are quite homely.
 
Posts: 858
Joined: Mon Mar 26, 2007 10:15 pm
Location: Billericay, UK

Postby Steve Anderson » Wed Jun 20, 2007 1:49 am

AncientBrit wrote:If you set aside a single level you lose only 1 in 255.

GL


Exactly my thoughts, I had considered using within 8-bit data for luminance just a single value for sync, say 00h, picture information would encompass 01h to FFh. Fits in very nicely to simple 8-bit .avi files.

Steve A.
User avatar
Steve Anderson
"Fester! Don't do that to 'Thing'"
 
Posts: 5360
Joined: Fri Mar 30, 2007 10:54 pm
Location: Bangkok, Thailand

Four bites please, baby.

Postby Steve Anderson » Wed Jun 20, 2007 4:05 pm

Now then Guys and Gals....

Attached is a conceptual hardware implimetation of the above. What I don't know is...

1) Can the PC keep up with the required data rate through the paralell port? This of course is dependant on the PC hardware.

2) Using Interrupts, how precise would the timing be? i.e. would the buffer/latch be needed? What is the latency within the interrupt routine?

3) Could this be expanded to four bytes at 48kHz? One for luminance, two for colour-difference channels, and one for 8-bit audio? This of course would require additional external harware.

Andrew, Gary, over to you, I'm no programmer...

As shown the gate produces sync only when the data is 00h, if changed from an OR gate to a NAND gate, then FFh would generate the syncs.

Steve A.
Attachments
Sync 4.gif
Sync 4.gif (14.08 KiB) Viewed 12830 times
User avatar
Steve Anderson
"Fester! Don't do that to 'Thing'"
 
Posts: 5360
Joined: Fri Mar 30, 2007 10:54 pm
Location: Bangkok, Thailand

Postby AncientBrit » Wed Jun 20, 2007 5:43 pm

Steve,

I've used the parallel port the other way around as an input from an NBTV interface.

The PC interrupts play havoc with timing so I used a 2kByte FIFO in the hardware.

One frame of 2048 bytes took 10mS to download into the PC.

This was some time ago and screen updating was slow so I used a technique that made use of modifying a bit map safe array to get the necessary speed.

The problem now is that RS232 and parallel ports are legacy devices.

There are external USB interfaces that purport to emulate these ports.
Whether they are bi-directional and support all pin protocols I have not yet tested.

Speed is another issue.
You will see from the above that I achieved a throughput on average of 5uS per 8bit pixel.

Not sure if these adaptors can support this speed.
The USB-RS232 would need to be running at 5/10 or 0.5uS per bit assuming a 10bit word

Regards,


Graham
AncientBrit
Green padded cells are quite homely.
 
Posts: 858
Joined: Mon Mar 26, 2007 10:15 pm
Location: Billericay, UK

Postby AncientBrit » Wed Jun 20, 2007 5:48 pm

Correction.

Since an NBTV frame is 80mS we would need a serial throughput of 5/10 * 8 = 4uS per bit or 250kbps.

GL
AncientBrit
Green padded cells are quite homely.
 
Posts: 858
Joined: Mon Mar 26, 2007 10:15 pm
Location: Billericay, UK

Postby Viewmaster » Wed Jun 20, 2007 6:30 pm

Ah, how PCs have advanced....on the old BBC micro there were two 8 bit ports, one could be configured as input/output in programming. So easy to use either in BASIC or assembly language.
Albert.
User avatar
Viewmaster
Frankenstein was my uncle.
 
Posts: 1306
Joined: Fri Apr 06, 2007 4:50 am
Location: UK Midlands

Re: Four bites please, baby.

Postby gary » Wed Jun 20, 2007 7:09 pm

Steve Anderson wrote:Now then Guys and Gals....

Attached is a conceptual hardware implimetation of the above. What I don't know is...

1) Can the PC keep up with the required data rate through the paralell port? This of course is dependant on the PC hardware.

2) Using Interrupts, how precise would the timing be? i.e. would the buffer/latch be needed? What is the latency within the interrupt routine?

3) Could this be expanded to four bytes at 48kHz? One for luminance, two for colour-difference channels, and one for 8-bit audio? This of course would require additional external harware.

Andrew, Gary, over to you, I'm no programmer...

As shown the gate produces sync only when the data is 00h, if changed from an OR gate to a NAND gate, then FFh would generate the syncs.

Steve A.


Steve, a PC is generally well able to keep up with this rate *providing* it is not running windows or a windows like OS, for instance DOS is fine.

However...

Now Ralph Taggart has designed a very nice parallel port NBTV input device (i.e. the reverse of what you are proposing):

http://taggart.glg.msu.edu/ich/nbtvcpu.htm

Which has a nice DOS interface. He asked if anyone was interested in developing a windows interface to this device and I took it up (perhaps a little optimistically).

I knew that the only way to approach this was to write a device driver since this is the only way to gain the exclusive access to the system that is needed to obtain the throughput - sans buffering (even a relatively small amount of buffering solves the problem otherwise). Of course when in video capture mode there would be no time left to service other window applications but when you've got a wonderful NBTV application running who cares?

This works well in terms of being able to process the video information. I have a prototype that takes the information in and displays it very well (keep in mind that the reverse process is even easier). Where I have come to a road block, rather infuriatingly, is that whilst in video capture mode there is no way to service mouse and keyboard events. That is not to say there isn't enough time to do that, because there is.., unfortunately, the standard drivers for mouse and keyboard do not work well with other device drivers, especially ones that are running at a much higher priority. I initially thought that I would, in kernel mode, be able to access the keyboard hardware directly, and in fact I can, but for some reason that I am not yet aware of this is unreliable. I thought that I would eventually stumble over a simple solution for this, but two years later I have still failed to do so. I could, of course, write a new keyboard device driver, but this is a major undertaking, and means the existing driver needs to be uninstalled so I would run the risk of disabling the OS if something went wrong.

Technically, I think it is possible to solve this problem, and I have not given up on it, just placed it on the back burner waiting for some critical piece of information to turn up. Strangely, no one else seems to have attempted to tackle this problem.

The other disadvantage of this method is that different OS's (i.e. 95, 98, NT, XP 2000, and now Vista) generally need different Device Driver paradigms and so there is no 'one size fits all' solution, however I felt that a solution that worked for NT, 2000, XP would be worthwhile as 95 and 98 can easily run the dos programme as it is.

Vista is another beastie all together but in fact it should make the device driver easier to create.

So as it stands it is possible to sustain the data rates under windows so long as you don't need to control it :-(

If anyone out there has any ideas on the subject I would be very grateful indeed to hear from them.
gary
 

Who's a nut?

Postby Steve Anderson » Wed Jun 20, 2007 7:16 pm

AncientBrit wrote:The problem now is that RS232 and parallel ports are legacy devices.


Yes, that is a concern of mine. So I downloaded "USB in a nutshell" hoping to be enlightned. It's a nut about the size of Mars! After plodding through the first few pages I wilted and gave up with a whimper.

The alternative is a data aquisition card with a number of I/O lines. I already have one I bought some years back, but it's ISA buss and therefore can't be used with my PC as it has no ISA slots, plus it's kinda useless for a laptop. Ever heard of the expression "As useful as a bicycle is to a fish"?

Good old-fashioned data I/O is becoming a thing of the past, plus there's always the headache of the OS getting in the way. Tried buying a Z80 or a 6809 recently?

There is the PIC/AVR route, but I think few would want to go down that path.

Steve A.
User avatar
Steve Anderson
"Fester! Don't do that to 'Thing'"
 
Posts: 5360
Joined: Fri Mar 30, 2007 10:54 pm
Location: Bangkok, Thailand

Re: Four bites please, baby.

Postby Steve Anderson » Wed Jun 20, 2007 7:41 pm

gary wrote:Steve, a PC is generally well able to keep up with this rate *providing* it is not running windows or a windows like OS, for instance DOS is fine.


*Panting like an out-of-breath Jack Russell* Yeah yeah!!

Steve A.
Attachments
elecdog1.jpg
elecdog1.jpg (41.05 KiB) Viewed 12797 times
User avatar
Steve Anderson
"Fester! Don't do that to 'Thing'"
 
Posts: 5360
Joined: Fri Mar 30, 2007 10:54 pm
Location: Bangkok, Thailand

Re: Four bites please, baby.

Postby Steve Anderson » Wed Jun 20, 2007 9:56 pm

gary wrote:Steve, a PC is generally well able to keep up with this rate *providing* it is not running windows or a windows like OS, for instance DOS is fine.


On a more serious note, what I am attempting is to get my main PC to dual-boot. Currently it runs Linux, it would be nice to be able to kick it into DOS mode occasionally. But that's something I should be able to do myself with enough persiverance. This would allow me to run nice, simple and fast applications as mentioned.

However, there is now a whole generation that have never seen the c: prompt and wouldn't know what to do from there. So there's a dilemma, there's no point in writing an application that few are going to use.

Somehow we need to patch code from a soundcard to work bidirectionally with a dedicated NBTV interface that negates the low-frequency problem, inputs/outputs four signals at the same time with minimal crosstalk and keeps accurate time. I would think that this is not a task for the faint-hearted.

The hardware interface for me is almost trivial (except USB at the moment), it's easy, it's the code that gets my panties in a twist!

Steve A.
User avatar
Steve Anderson
"Fester! Don't do that to 'Thing'"
 
Posts: 5360
Joined: Fri Mar 30, 2007 10:54 pm
Location: Bangkok, Thailand

Postby AncientBrit » Wed Jun 20, 2007 11:01 pm

What I'm currently building is an VGA RGB hardware interface to parallel port.

The hardware part is PIC based and writes a frame of RGB to RAM.
That part is built with the PIC programmed.

For interfacing to the PC I'm still sticking with the parallel port running in Windows.

Code is currently being developed in VB6 and I'm about to carry out some speed tests to see if I can compress all the read from PIC/write to PC memory/Write to screen operations into 63mS.

(80mS of NBTV frame rate less the 16.6mS of VGA write to RAM)

I'm not attempting interleaved write and read, rather a separate grab and then read out.

As I say I've had experience of this before and last time I used a 2k FIFO to buffer Microsoft from the real world, but that was monochrome only.
Colour places a 3 times loading and I think I may struggle to fit it all in.

But there is some way to go and I like to take it easy so don't hold your breath.

Regards

GL
AncientBrit
Green padded cells are quite homely.
 
Posts: 858
Joined: Mon Mar 26, 2007 10:15 pm
Location: Billericay, UK

PreviousNext

Return to Mechanical NBTV

Who is online

Users browsing this forum: Google [Bot] and 28 guests

cron