Retro SSTV anyone?

[M3DVQ]

I don't know of any quick way to do it, but one technique I have seen is to use a polishing compound like "T-Cut" to carefully polish away screen printed legends without stripping the paint below. Whether that would work on the sort of paint heathkit used I don't know. The wrinkly surface possible renders that technique impractical if not impossible though

I imagine that fabricating a fake product convincingly would involve a lot of the techniques used in model making and prop making/reproduction.

[Steve Anderson]

An idea...obtain a very heavy grade photo-printing paper (for ink-jets or lasers) which has a very matte finish rather than the usual glossy finish. You may have to go to a specialist photo-shop for this. Then print as usual and use as an escutheon.

Those knowledgeable about Heathkit would know it's a 'fake' and that this model was never produced. Those less knowledgeable (me) would take it on face value - rather like a counterfeit banknote.

The downside is over time the print would pick up dirt and fingerprints. But for a photo-shoot or a one-off exhibit it may pass.

Depending on the mechanical arrangements of the front panel it maybe a fairly quick exercise to print off a new one and replace it when required...it's one alternative.

Steve A.

[Klaas Robers]

Steve,

I think that, when everything is mounted and working, that I firstly make a colour print on normal A3 paper and glue that with photo glue on the unchanged front. Then I get an idea of how it could look like. Photo glue can simply be removed by gently rubbing without any remains. Of course I reinstall everything and I can use the SSTV-monitor for some time.

Then, when the paper gets dirty, I can replace it for a next print-out, may be on somewhat thicker paper. I can try to spray the surface first with some kind of plastic spray before I glue it on the aluminium front. May be that helps.

In the mean time I might get more information on how to remove the white paint and place new texts, may be using transfers or whatever. In this way I shift the decision further in time. Sometimes that helps.

[Steve Anderson]

In the background I have been building a SSTV-625 up-converter which only works with the original Copthorne McDonald SSTV FM standard. No VIS codes, no colour and 120/128 lines only. It handles both US (15Hz) and EU (16.7Hz) line-rates. If there is software out there that will handle this standard and run on a modern PC, it hasn't been found yet. Anyway I don't really want to use a PC except as a replacement for a tape-recorder.

The screen-shot below shows the results so far. The source of the SSTV signal is the 8kHz/8-bit file Klaas posted in this thread a while back. It looks no different to the same pattern sampled at 48kHz/16-bit...and I mean no different.

There are issues I need to fix...

1) The display is 128-lines whereas the source file is 120-lines hence the additional eight lines at the bottom that will need blanking.
2) The video levels are unprocessed which is why the black bar is actually mid-grey.
3) There's an oddity visible in the bottom-right white bar, it has a vertical black bar of one pixel wide for some reason [1]. The others have the same but they're less visible in the snapshot. It'll be a silly for sure. The RAM is OK as on the internally generated pattern at start-up there's no problem at all. It's probably a software/timing hiccup.
4) The aspect ratio is slightly 'off', I need to get the correct crystal of 7.3728MHz in place of the 8.000MHz one I'm currently using.


Now for NBTVers this unit will also handle NBTV-625 too...in due course. There's no difference in the hardware except that for NBTV you'll need a DC-restorer (simple) in place of the SSTV demodulator (not so simple). Both the SSTV and NBTV software fit into the one processor's program space so you can select whichever mode you wish. The display device used here is an old 21" CRT JVC domestic TV, I'll eventually use a flat-panel TV to get rid of the curvature distortion. The patterning is a result of the shadow-mask tube and the pixels in the camera, it's not there when viewed normally.

More to come.

Steve A.

[1] The SSTV line is sampled 256 times in the active video period which is why the rouge pixel looks quite narrow. The display is also of 240/256-lines. Currently the lines are simply repeated to generate 240/256 lines which fit nicely into the 625 active picture area per field. The display is correctly interlaced.

[Steve Anderson]

As a follow-up, here's a short video that shows initially the internally generated test-pattern then the incoming SSTV, it takes a while to lock awaiting the vertical sync pulse.

My niece has borrowed my tripod for a week - three months ago - so I had to hand-hold this....

Steve A.

[Harry Dalek]

Excellent to see it working ,i would be pretty proud of that gadget Steve i know you still have a few little problems but not many of us can make something like that from scratch i know i can't .Looking forward to images in time .

[Steve Anderson]

Excellent to see it working...Looking forward to images in time .

Thanks Harry. It still has a way to go to be able to say 'it's done'. There's still all the controls to add in, black level, white level (gain/contrast), sync slicing, gamma adjustment, sample rate, freeze frame and also three types of line interpolation. The last one being the trickiest!

I also want to beef up the sync detection algorithm such that it can handle noisy signals - well, to some degree anyway. I doubt I could match the like of MMSSTV and many others.

As for 'real pictures', yes, I need to address that! All of the more recent PC software generates VIS tones at the start of each frame and drop the frame sync pulse. So I'm going to have to do it somehow myself. I have a half-finished unit that with some extra RAM and some filters should do it. I'm undecided exactly how to do it - do I 'fudge' the existing unit as mentioned or build a purpose-made device?

The small DDS modulator mentioned earlier in this thread can do the actual SSTV sub-carrier generation, I just need somehow to strip off the header and trailer from TIFF files (the picture data is uncompressed and eight bits in monochrome, at least in the format I save them in).

I guess it's a case of 'watch this space'.

Steve A.

Photo shows the Read uC undergoing programming, it also shows just part of the mess created! The bundle of mostly white wires to the left are from the aforementioned front panel controls.

[Klaas Robers]

Marvellous Steve, good work.

In the mean time I am busy on my Radar tube monitor in the SB-500 cabinet. In the monitor the SSTV picture generator (in DTL) that I built in 1973 will be included. Mostly I start to make a generator that gives standardised signals. This I did too for SSTV, however I think it was the first project that I did that for. In the mean time I added an EPROM PCB that can hold 64 pictures, although I made just a few as it is quite some work. I think I can record an SSTV-file for you, containing one or more of those pictures. How many frames do you need to make a photo? And then 8 bits at 8 kHz is good enough?

[Klaas Robers]

Steve, how does this SSTV wave file look like as a picture? I haven't seen it yet .... It is uploaded from the EPROM.

[Steve Anderson]

Klaas, thanks for the file, it's useful to have a variety of files from various sources to shake-down the gear.

I had to set the sync-slice level quite low as there's quite a lot of overshoot within the video signal. I don't know if that's a deliberate 'sharpening' idea or it's a minor error. The waveform below isn't the best example but I hope you get the idea, the waveform is straight out of the analogue demodulator, it hasn't been digitized at this stage. With that in mind the attached photo was about the best I could get on the screen.

Now this problem may go away when I beef up the sync detection algorithm to ignore narrow pulses like the overshoot mentioned above. Give me a day or two and I hope to get better results. There doesn't appear to be anything inherently wrong with the signal. It's interesting to note that the lines that make up the castllations and those with text are much better than the others...in fact it's the lines that start and end on white that are OK, the others have this 'tearing' problem. I need to get on to this...

I would say that four frames would be enough to lock, say 30 seconds or so, I'll also add-in the frame-freeze function which is (should be) quite simple. 8kHz/8-bit is fine now I've got that sorted out.

Steve A.

Klaas, if you have the raw data for that file I could try and compile it myself - though that won't be tomorrow - just to see what (if any) difference there may be.

[Klaas Robers]

Steve, thanks for placing the picture and the wave form. I recognise the wave form to be of one of the upper or lower lines, black and white blocks, with in the middle the small white arrow. This is the sharp pulse in the middle of the line.

There is no sharpening in the video signal. However there is also no bandwidth limitation done before the FM modulator. I see too that there is quite some ripple on the video, which is not present in the bottom of the sync. I am going to look more in detail to my FM modulator. I have seen rippling on the video signal. It could be caused by the FM carrier that is generated there. May be it needs an extra smoothing capacitor.

On the other hand I am pleased to see that in the multi burst the highest definition lines (frequency) are coming out fine. The frequencies are: 400Hz, 600Hz, 800Hz and 1200Hz. I had my doubts about the 1200Hz, if that could be FModulated on the AF subcarrier. But apparently it does. I keep then in this picture.

Can you try to capture the analogue demodulated wave form of one of the lines starting and ending with black? Then you may see what happens at the beginning of the sync pulse. In your picture I see something white at the end of these lines. I can't imagine where that comes from. The sync pulse should be displayed as (blacker than) black, isn't it?. Preferably it is one of the lines with the multi burst in the center, to see the frequency response of the video signal as well.

I should also look more carefully into the recording process. I recorded using Gold Wave, but I saw some interruptions in the wave form in the beginning of the signal. This was clipped off in Gold wave. Yesterday I had no time to look further into that, but I should do. May be I had a bad contact in the audio channel (two wires with crocodile clips) from the electronic circuit to the laptop, but it is also possible that the laptop had some problems to record at the 8 kHz sample rate. I will see. May be you get a new file.

[Steve Anderson]

I recognise the wave form to be of one of the upper or lower lines, black and white blocks, with in the middle the small white arrow. This is the sharp pulse in the middle of the line.

I would guess that as the main timebase says it's around line 4 or 5. A delay of 211ms as noted at the top of the waveform screen. The timing reference is vertical sync

I see too that there is quite some ripple on the video, which is not present in the bottom of the sync.

Yes, that's odd. The demodulator can produce a negative output if the sync frequency is slightly low, but why there's no overshoot or ripple I really dont know.

On the other hand I am pleased to see that in the multi burst the highest definition lines (frequency) are coming out fine. The frequencies are: 400Hz, 600Hz, 800Hz and 1200Hz. I had my doubts about the 1200Hz, if that could be FModulated on the AF subcarrier. But apparently it does. I keep then in this picture.

It's worth leaving the 1200Hz in as I intend to work on an improved demodulator in the future. The current one is basically a Robot 70 brought up-to-date, otherwise fundamentally it's no different...gotta hand it to those Robot guys! But as you'll note in the waveform to follow in the next posting, the 1200Hz is somewhat attenuated...but that's no surprise though. I'm surprised it's there at all!

Can you try to capture the analogue demodulated wave form of one of the lines starting and ending with black? Preferably it is one of the lines with the multi burst in the center, to see the frequency response of the video signal as well.

Can do...give me a little while...

Steve A.

I've just realized...nice call-sign! If I still had my UK call I guess something like G1STV would be appropriate...given the TV interest too.

[Steve Anderson]

Here's one of those occasions when a good old-fashioned analogue 'scope wins over a digital version...

But looking anyway at the waveforms below you can see the 1200Hz modulation is severely attenuated, yet it is still visible to an extent in the screen display.

Now the thing is that the 'scope quite happily triggers on the sync pulse in either format, so why doesn't the up-converter? I need to spend some time on this...the scope though is triggering from the vertical pulse with a 4.8 second or so delay...This I'm sure is an issue at this end, this device should be able to handle this....the source file though a bit 'rough' in places (meant in the nicest possible way) and it should really be no problem, so it's me that needs to sort this out...

Steve A.

What would help is either the raw data file and/or exactly how this file should look.

[Klaas Robers]

Steve, what do you mean with "the raw data"? How raw is raw?

The picture should look like the gif-file attached. This gif picture is not square, but the horizontal dot frequency of the hardware video generator is 4800 Hz, which gives 132 dots in the active line.
The circle is also not round in the gif picture, but on the screen of the monitor it should be a perfect circle.
Also the first line is black. This gives an odd number of lines, which makes it possible to draw a horizontal centre line.
In practice the first line is for the second half filled with video. The first half of course is V-sync.

[Steve Anderson]

That's a great help knowing what it should look like. You can guess from the waveform but there's nothing like a picture to help put it all together.

By 'raw' I mean somehow you must have built this up pixel-by-pixel or somehow generated a binary file to burn into the EPROM.

But now I know its layout I can attack this problem better armed...a day or two I hope to have it sorted out. It's going to be a 'silly' as they usually are with software...

Steve A.