Want to resurrect your D/D2 MAC kit?

Reminds me of back when I was thinking about doing something similar with my Pace MSS300 analogue box, wasn't really met with much enthusiasm... :-lol
 
So captured two frames worth of output from the pattern generator with my oscilloscope, and transferred it to the PC and some gnuradio magic later had it transmitting FM to the receiver in a loop:


(Apologise for the bad music, had to replace the background music in the recording to avoid the copyright thugs)

So, progress! It isn't syncing at all. I only captured the signal at 5MHz, which might be too slow. It's also possible the signal generator is producing D2-MAC signals rather than D-MAC.
 
Captain Jack said:
That's very interesting.

@fsphil are you going to try to splice real video signal into the MAC generator? I haven't looked in any great detail on mine but I think I isolated the part of the board that encodes the pattern generator into MAC. Need to probe a little!
Click to expand...

The manual seems to imply that there isn't a dedicated encoder in there. It stores the test patterns already prepared and just sends them straight to the output DAC from the ROM. There must be some extra bits to add the digital data in but other than that it doesn't seem to do much processing.
 
Ah, that sounds about right. And annoying. Was hoping for something more exciting than test patterns!
 
Welp, mine seems a little annoying as something keep drifting - either a power supply or an oscillator. Or something else. It keeps losing lock and there's some odd interference going on as well on all patterns - it seems unrelated to the pattern selected.

After being switched off for a while, it works fine and there's no interference at all for up to around 30 seconds but then eventually comes back to this. Most components inside are from the 80's, so I guess some drift is expected! I adjusted a few pots, including the frequency adjuster to 20.25MHz but none seemed to make any difference. Maybe some earthing issue? Not sure...

 
fsphil said:
So, progress! It isn't syncing at all. I only captured the signal at 5MHz, which might be too slow. It's also possible the signal generator is producing D2-MAC signals rather than D-MAC.
Click to expand...
Any chance of sharing the flowgraph file for GNU Radio?
 
Captain Jack said:
Any chance of sharing the flowgraph file for GNU Radio?
Click to expand...

It's here: d-mac-tx.grc · GitHub

It just replays the frames I captured from the test generator. I've confirmed that the generator is D2-MAC rather than D-MAC. It can do D-MAC but it needs different firmware, which I doubt is easy to get these days :)

I've written some code to generate my own D-MAC-ish signal, seeing what the minimum this Philips receiver needs to get a good picture. With just the frame and line sync patterns I can get it to lock but only ever for a brief moment before the image starts wandering again.

And I thought this would be easy :)
 
On the rear panel of the UST92 there was a two way switch to allow raw or filtered signal into the first stage from the receivers video output, but I;ll be damned if I can remember the exact parameters . One would allow a better sync with the Uniden receiver - UST7007- and the other with the Drake EST324 and Gensat 4/12 I had as backups.
 
I was perusing ebay earlier and found this Pace MRD960 MAC decoder apparently new-in-box for sale:

Code: 
http://www.ebay.co.uk/itm/131104349006

And at the time of posting, there's two for sale (no, I didn't buy the already sold one!!!), dunno if they're any good for play, but maybe worth a look... :)
 
fsphil said:
It's here: d-mac-tx.grc · GitHub

It just replays the frames I captured from the test generator. I've confirmed that the generator is D2-MAC rather than D-MAC. It can do D-MAC but it needs different firmware, which I doubt is easy to get these days :)

I've written some code to generate my own D-MAC-ish signal, seeing what the minimum this Philips receiver needs to get a good picture. With just the frame and line sync patterns I can get it to lock but only ever for a brief moment before the image starts wandering again.

And I thought this would be easy :)
Click to expand...
Thank you, Phil. Would you be able to push the source .bin file along with your own generator code as well? I am just getting to grips with gnuradio - it's a very steep learning curve, but possibilities seem endless! What are you using for transmitting, hardware-wise - HackRF? I've seen on YouToob the possibility of transmitting your own DVB-S2X channels from just about any source, so no reason why the same couldn't be done for MAC. The audio part might be tricky but implementation itself seems simple enough.

My generator is D/D2MAC as well but I've no idea how to switch between the two. The only difference I can see is that D2MAC is using half the data rate of DMAC (10.125Mbit/s instead of 20.25Mbit). I have a 20.25MHz crystal inside but without an oscilloscope, I am not sure what it's actually pumping out. And "MAC information" menu option doesn't tell me...my decoder is D/D2MAC compatible, so could be either!
 
Last edited:
Here's the sample and updated grc flow graph which can display the input visually: https://www.sanslogic.co.uk/d2-mac-sample.zip https://www.sanslogic.co.uk/d2-mac-sample.png

Transmitter is a HackRF. In theory it can produce any kind of signal up to about 20MHz wide, which isn't quite enough for a proper D-MAC FM signal as it would have come from the satellite. I'm using a much lower deviation and hoping that the receiver can compensate. When I've done the same with PAL and an old Sky box it worked fine. :)

I've included the current d-mac.py generator script in there too, it takes a video sample.mp4 file and produces a baseband D-MAC signal samples.bin at the required 20.25MHz sample rate. It's not pretty code, just threw together to try things out. The data bursts are just filled with random data, the sync codes should be fine and I've copied the line 625 data from the R+S pattern generator output. It's written in python3 and uses ffmpeg to decode the video file.
 
Very cool! This Python code could be converted to a custom GR block and do it real time...though on my VM it's only running at about 2.5 fps. Still, it converted it OK - used an old Filmnet+ ident video :D Had to change the input width to 1296 as per code, else it was all scrambled. I guess you could create a decoder inside gnuradio too but that defeats the point somewhat and it's way beyond my knowledge...

Are you able to generate D2MAC or do you not have the necessary data for that? I assume it's more than just halving the clock rate.

Looking forward to more experiments! Maybe audio next?

Now need to invest in HackRF but they are quite pricey.

Screenshot 2017-05-07 16.51.18.webp
 
Here's what it looks like on the BSB receiver I got, also with hardware era appropriate video :)


You can see it seems to lock onto the image a few times for just a moment. I can't rule out a fault in the receiver, but it's most likely something I'm doing wrong in the signal or how I'm transmitting it.

D2-MAC seems to be basically the same thing, just half the clock rate. If we can get one working the other would be simple. Famous last words.
 
Nice, you're certainly very close! Seems to moan about "poor signal level" when it does lock, though that seems a little weird. Could it be to do with VCO? I remember I had to adjust this on Philips FilmNet to stop it losing lock on flashing images with my Amstrad 510.
 
Some more retro stuff... http://ibsoftware.free.fr/cryptimage.php - this allows you to encrypt and decrypt any video in Videocrypt, Nagravision (Syster) and Discreet. I tried it out and it looks very authentic. Decryption isn't perfect but it's good enough for proof of concept... There's also source code available on the same site. Don't think gnuradio is capable of injecting VBI data by default...

@fsphil - have you managed to transmit a full moving video in PAL or just a still image made up of y and uv parts?
 
fsphil said:
Here's what it looks like on the BSB receiver I got, also with hardware era appropriate video :)


You can see it seems to lock onto the image a few times for just a moment. I can't rule out a fault in the receiver, but it's most likely something I'm doing wrong in the signal or how I'm transmitting it.

D2-MAC seems to be basically the same thing, just half the clock rate. If we can get one working the other would be simple. Famous last words.
Click to expand...


That image is characteristic of filtered baseband being sent to the decoder, try taking the signal direct from an earlier 'raw' section of the receiver circuitry.

Some decoders had a software switch to compensate, the Uniden was hardware (and easy)
 
As Phil's receiver is a pure DMAC receiver ( BSB ), I would have thought that it's already fed an appropriate baseband internally.

On my Philips I can pick between PAL, flat and MAC deemphasis inputs through the menu. Works best on MAC option from the generator. In PAL it locks occasionally - similar to the video above.


I bought the HackRF unit today, so will test it out here as well once it's all setup.
 
The horizontal scrolling effect reminds me of Channel 4's older idents where they did something similar...
 
Some great info here, which I suspect is where Phil got his information from to generate MAC samples:

http://www.etsi.org/deliver/etsi_i_ets/300200_300299/300250/01_60/ets_300250e01p.pdf

Especially interesting is the implementation of the CA system. Looking at the data structure, setting the last 3 bit appropriately, will tell the decoder whether to try decoding the signal.

Code: 
bits += self.bits({ 'len': 8, 'code': 0x10000000 }) # TDMCID (8 bits)

From page 24:

Screenshot 2017-05-08 17.07.32.webp

Does that mean that with bits set to 000, my decoder will try to unscramble the signal in "free" mode (using local CW) - a la MTV Germany? We could potentially make encrypted files with a set cut/rotate sequence and get the decoder to decrypt it in "free access" mode (or soft encryption). I suspect, it will be a bit of a challenge but hey...
 
Back
Top