Satellite multiplex 11307H - copy of Freeview PSB2 Bilsdale

[NY]

I know that 11307H was used as a temporary copy of Bilsdale's PSB2 to
distribute the mux to relay stations while Bilsdale itself was not able to
distribute the mux by Freeview.

But is it still needed? Is the coverage of the temporary Bilsdale still not
good enough to reach some of the relays? I presume it will be freed up once
the full-height Bilsdale is in service.

[Mark Carver]

Yes, it's still being used at almost all of the relay sites I think. A
couple have been retuned to Pontop though.

Also, it allows them to interrupt the transmissions from the temporary
mast,  without the relays going off

http://tx.mb21.co.uk/gallery/gallerypage.php?txid=747&pageid=4218

[Brian Gaff]

So you should be able to detect a delay from the ones fed from the sat
against the others if you can get two sets in the same place to receive
both.
Brian

--

--:
This newsgroup posting comes to you directly from...
The Sofa of Brian Gaff...
bri...@blueyonder.co.uk
Blind user, so no pictures please
Note this Signature is meaningless.!
"Mark Carver" <mark....@invalid.invalid> wrote in message
news:jg49r3...@mid.individual.net...

[NY]

"Brian Gaff" <brian...@gmail.com> wrote in message
news:t7l7ev$l2r$1...@dont-email.me...

> So you should be able to detect a delay from the ones fed from the sat
> against the others if you can get two sets in the same place to receive
> both.

In the mid 1990s, in my first house, I could receive ITV from both Crystal
Palace and Hannington - in fact Bracknell Cable provided both, modulated
onto different UHF channels. One day, by chance, I had my TV tuned to
Hannington with its sound turned up and my VCR (which was feeding sound
through my hifi) tuned to Crystal Palace. Everything was analogue - apart
from the VCR sound by NICAM, and I eliminated that - and yet I could detect
a very slight delay between one and the other: just enough to "thicken" the
sound without being noticeable as a definite echo. Probably the sort of
difference that was typically used by "flanging" effects boxes. I turned my
VCR to use the FM sound (like my TV) which surprisingly made no discernable
difference (probably the "near instantaneous" part of NICAM!). And if I
retuned the VCR to Hannington, as for the TV, the delay went away. So
something in the analogue distribution system between studio and my
equipment was inserting a very slight delay in one signal compared the
other. The different signal path is about 70 km, assuming line of sight.
Assuming signal propagates at the speed of light, this equates to about 0.2
milliseconds. Could the brain detect that? Of course, the signal paths could
be longer than the line-of-sight difference and the signal may be
propagating at some fraction of c: both of those would increase the delay of
one compared with the other.

Would propagation alone be the cause, or could there have been an additional
signal-processing stage in one leg that would cause a very small delay -
much, much less than the sort of delay that you typically get nowadays
between two digital TVs that are tuned to the same transmitter? In the
mid-1990s, would there have been any digital processing stages between the
studio output and the receiver? Nowadays if you are comparing terrestrial
with digital there will be a delay of about 250 milliseconds between the
two, even if the digital stages insert the same delay which is unlikely.

Yes, I know I had too much time on my hands and was being geeky when I
pondered that question :-)

[Mark Carver]

On 06/06/2022 17:36, NY wrote:
>  In the mid-1990s, would there have been any digital processing stages
> between the studio output and the receiver?

Loads, frame store synchronisers all over the shop. The delay you heard
was nothing to do with any propagation delays, they would have been
microseconds (do the maths, using 2/3rds the speed of light)

Frame Store Syncs, add, well, the clue is in name isn't it ?

[NY]

"Mark Carver" <mark....@invalid.invalid> wrote in message

news:jg6p12...@mid.individual.net...

> On 06/06/2022 17:36, NY wrote:
>> In the mid-1990s, would there have been any digital processing stages
>> between the studio output and the receiver?
>
> Loads, frame store synchronisers all over the shop. The delay you heard
> was nothing to do with any propagation delays, they would have been
> microseconds (do the maths, using 2/3rds the speed of light)

Yes I did the maths (apart from using c rather than (2/3).c) - it comes out
at 133 usec (or 0.1 msec). My question was whether the ear is sensitive to
hearing such a short time delay. My guess is no!

> Frame Store Syncs, add, well, the clue is in name isn't it ?

Ah, I wasn't sure whether they would be used on one route (to one
transmitter) and not another (to a different transmitter). A delay of 1/25
second (40 msec) is far more plausible than a delay of 0.1 msec ;-)



Mind you, I'm not *certain* that the signals which Bracknell Cable TV
distributed were even received from Crystal Palace and Hannington
themselves, as opposed to from relays - only that I got TVS from one and
Thames/LWT from the other. If one was a relay, there could be a frame store
at the relay to correct for any timing jitter in the signal received from
the main transmitter.

The more weird thing was on another occasion when I was tuning the output of
the VCR to find a vacant slot in the UHF spectrum for it to "talk" to the
TV. At one stage I tuned it too close to a broadcast signal and got
co-channel interference between one channel off-air and another channel via
the VCR and its frequency-shifting. So I got the well-known cross-pattern,
where TV was syncing off one channel but displaying the video of the other
channel. Nothing special there, but... I was surprised that the video rolled
at a rate of about once a minute. I'd expected that all TV signals would
have used the same line rate (different crystals at the same nominal
frequency) and I was surprised that there was a discrepancy of about 1
cycle/minute. I presume it was different broadcasters (eg ITV and BBC)
rather than two channels from BBC which almost certainly would have shared a
common reference frequency. What is the typical permitted error between one
broadcaster's reference frequency and another? Would a small error in line
frequency affect colour decoding? I presume the PAL crystal in a TV is
nowhere near as tightly controlled as the studio reference frequency, and
PAL has to be able to cope with that, hopefully producing saturation rather
than hue errors. I realise that before colour, TVs synced to the mains, so
tuners had to cope with a variation in field rate of 50 +/- 0.5 Hz.

[Woody]

When I used to do quasi-sync radio system setups (by the bucket load!) I
used the free space signal propagation time as 5.38uS per mile, so 70Km
would give about 234uS. No matter how hard you try you won't hear that!

[Mark Carver]

On 06/06/2022 22:32, NY wrote:
>
> Mind you, I'm not *certain* that the signals which Bracknell Cable TV
> distributed were even received from Crystal Palace and Hannington
> themselves, as opposed to from relays - only that I got TVS from one
> and Thames/LWT from the other. If one was a relay, there could be a
> frame store at the relay to correct for any timing jitter in the
> signal received from the main transmitter.

Err no. You'd never do that, or need to. In any case, relays didn't take
the video and audio down to baseband

>
> The more weird thing was on another occasion when I was tuning the
> output of the VCR to find a vacant slot in the UHF spectrum for it to
> "talk" to the TV. At one stage I tuned it too close to a broadcast
> signal and got co-channel interference between one channel off-air and
> another channel via the VCR and its frequency-shifting. So I got the
> well-known cross-pattern, where TV was syncing off one channel but
> displaying the video of the other channel. Nothing special there,
> but... I was surprised that the video rolled at a rate of about once a
> minute.

I'm surprised the difference was that much, unless one of the channels
was 'fast genlocking', which was a thing in the 70s before frame store
syncs came along.
I used to amuse myself with the same trick, the drift was far far less
than that, well less than a frame per hour

> I'd expected that all TV signals would have used the same line rate
> (different crystals at the same nominal frequency) and I was surprised
> that there was a discrepancy of about 1 cycle/minute.

What do you mean by 'cycle' ? A frame ?

> I presume it was different broadcasters (eg ITV and BBC) rather than
> two channels from BBC which almost certainly would have shared a
> common reference frequency. What is the typical permitted error
> between one broadcaster's reference frequency and another? Would a
> small error in line frequency affect colour decoding? I presume the
> PAL crystal in a TV is nowhere near as tightly controlled as the
> studio reference frequency, and PAL has to be able to cope with that,
> hopefully producing saturation rather than hue errors. I realise that
> before colour, TVs synced to the mains, so tuners had to cope with a
> variation in field rate of 50 +/- 0.5 Hz.

These days master SPGs are locked to a GPS (or similar) timing reference.
Back in the day the BBC/IBA/EBU spec for sub-carrier frequency was
4.43361875 +/- 1 Hz with a rate of change of no more than 0.1 Hz/sec

The line and field rates were derived from that s/c reference (Usenet
doesn't allow the formula to be easily displayed !)

[NY]

"Mark Carver" <mark....@invalid.invalid> wrote in message

news:jg8crh...@mid.individual.net...

>> I'd expected that all TV signals would have used the same line rate
>> (different crystals at the same nominal frequency) and I was surprised
>> that there was a discrepancy of about 1 cycle/minute.
>
> What do you mean by 'cycle' ? A frame ?

The time taken for the cross (border of one frame, visible on the TV screen
which was syncing on the other co-channel) moving from one extreme to the
other and back to its original position.

>> I presume it was different broadcasters (eg ITV and BBC) rather than two
>> channels from BBC which almost certainly would have shared a common
>> reference frequency. What is the typical permitted error between one
>> broadcaster's reference frequency and another? Would a small error in
>> line frequency affect colour decoding? I presume the PAL crystal in a TV
>> is nowhere near as tightly controlled as the studio reference frequency,
>> and PAL has to be able to cope with that, hopefully producing saturation
>> rather than hue errors. I realise that before colour, TVs synced to the
>> mains, so tuners had to cope with a variation in field rate of 50 +/- 0.5
>> Hz.
>
> These days master SPGs are locked to a GPS (or similar) timing reference.
> Back in the day the BBC/IBA/EBU spec for sub-carrier frequency was
> 4.43361875 +/- 1 Hz with a rate of change of no more than 0.1 Hz/sec
>
> The line and field rates were derived from that s/c reference (Usenet
> doesn't allow the formula to be easily displayed !)

Ah, I suppose the CSC frequency is the thing that would have a crystal, with
the line frequency being derived from

f(CSC) = 283 * f(L) + 25 Hz (if I've remembered the constants correctly)


I presume that if modern SPGs are locked to GPS (ie all to a common
reference), there should be no discernable drift between one channel and
another, though it is not easy to tell, given that co-channel interference
isn't visible on digital - one of digital's benefits.

[Mark Carver]

On 07/06/2022 09:33, NY wrote:
> "Mark Carver" <mark....@invalid.invalid> wrote in message
> news:jg8crh...@mid.individual.net...
>>> I'd expected that all TV signals would have used the same line rate
>>> (different crystals at the same nominal frequency) and I was
>>> surprised that there was a discrepancy of about 1 cycle/minute.
>>
>> What do you mean by 'cycle' ? A frame ?
>
> The time taken for the cross (border of one frame, visible on the TV
> screen which was syncing on the other co-channel) moving from one
> extreme to the other and back to its original position.

So one line then ? Horizontal movement, not vertical ?  In which case,
yes, that sort of drift was typical

>>
>
> Ah, I suppose the CSC frequency is the thing that would have a
> crystal, with the line frequency being derived from
>
> f(CSC) = 283 * f(L) + 25 Hz (if I've remembered the constants correctly)

That's about it

>
>
> I presume that if modern SPGs are locked to GPS (ie all to a common
> reference), there should be no discernable drift between one channel
> and another, though it is not easy to tell, given that co-channel
> interference isn't visible on digital - one of digital's benefits.

Impossible to see timing differences between TV stations with DVB
anyway, if you think properly about it.......

SPG accuracy  is even more important for IP based broadcast systems, and PTP

https://dbbroadcast.co.uk/wp-content/uploads/2018/02/dB-Broadcast-explains-PTP.pdf

[J. P. Gilliver (John)]

On Mon, 6 Jun 2022 at 22:32:41, NY <m...@privacy.invalid> wrote (my
responses usually FOLLOW):
[]

>Yes I did the maths (apart from using c rather than (2/3).c) - it comes
>out at 133 usec (or 0.1 msec). My question was whether the ear is
>sensitive to hearing such a short time delay. My guess is no!

Depends. Two signals with a delay mixed and played through a single
loudspeaker will experience (I think) a comb filter effect; for a delay
of 0.1 ms, the teeth of the comb will be 10 (or 5 or 20 - CBA to get my
mind round it) kHz apart, so it'd be just the bottom "tooth" you'd hear.
(The signals would cancel at some frequencies, double at others, and
variable in between. This probably _would_ be audible, but as a strange
filtering effect, not a delay.)

If through two different speakers, then you need to consider the speed
of _sound_: I've just looked it up, and the first source I tried said
343 m/s at 20°C in dry air at sea level, which is 343mm - 13½" - per
millisecond, or 1.35 inches (34mm) in 0.1 ms. Your two speakers are
likely to be further apart than that, not to mention echoes off the
walls etc. - so I'd say no, your ears (actually brain) would not detect
that sort of delay - or rather, are used to ignoring delays/variations
considerably more than that anyway. (The part of the brain that
determines the _direction_ of a sound source might use such small
amounts [differences between what reaches your two ears], but I assume
you know where your speakers are anyway!)
[]

>line frequency affect colour decoding? I presume the PAL crystal in a
>TV is nowhere near as tightly controlled as the studio reference

True - it is (or was) about the commonest frequency made, but even so
cheap crystals can have a tolerance as poor as 500 ppm, but ..

>frequency, and PAL has to be able to cope with that, hopefully

... that's what the colour burst at the start of every line is for - to
give the local oscillator in the set a frequency, and more important a
phase, reference. So the set only needs to hold the reference for one
line - 64 μs (less actually because of sync pulse and porches).

>producing saturation rather than hue errors. I realise that before
>colour, TVs synced to the mains, so tuners had to cope with a variation
>in field rate of 50 +/- 0.5 Hz.

I think some Baird Televisors used the mains, but for the frame/field
sync., no, that's what the sync pulses are for - even system A ("405"
lines) had sync. pulses. (Think about it: how did battery TVs work!)
Colour sets didn't do sync. any differently to monochrome sets - they
certainly didn't divide down the colour subcarrier, or multiply up to
it. Yes, the frequency of the subcarrier was _selected_ to have a very
precise relationship to the line and field pulses, but that was to
minimise artefacts (such as dot patterns, especially on B/W sets) - sets
did not do the divisions/multiplications inherent in that selection.
(You only have to look at what home VCRs did to the colour signals, and
sets still worked with the output from those!)
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

She looked like the kind of girl who was poured into her clothes and forgot to
say when - Wodehouse

[NY]

"J. P. Gilliver (John)" <G6...@255soft.uk> wrote in message
news:tXSbS6N7CzniFw+i@a.a...

>>line frequency affect colour decoding? I presume the PAL crystal in a TV
>>is nowhere near as tightly controlled as the studio reference
>
> True - it is (or was) about the commonest frequency made, but even so
> cheap crystals can have a tolerance as poor as 500 ppm, but ..
>
>>frequency, and PAL has to be able to cope with that, hopefully
>
> ... that's what the colour burst at the start of every line is for - to
> give the local oscillator in the set a frequency, and more important a
> phase, reference. So the set only needs to hold the reference for one
> line - 64 μs (less actually because of sync pulse and porches).

The problem comes when the colour is encoded at one frequency and decoded at
another frequency (because of tolerances in the receiver crystals). The
colour burst gets the local frequency into the correct phase initially, but
it the drifts out of phase because the frequency is slightly different. And
being double-sideband modulation, you don't a frequency shift (as with SSB),
you get periodic fading. I suppose in a really bad case where the frequency
difference has a period less than a line period, you start to see variations
in saturation across each line.

>>producing saturation rather than hue errors. I realise that before colour,
>>TVs synced to the mains, so tuners had to cope with a variation in field
>>rate of 50 +/- 0.5 Hz.
>
> I think some Baird Televisors used the mains, but for the frame/field
> sync., no, that's what the sync pulses are for - even system A ("405"
> lines) had sync. pulses. (Think about it: how did battery TVs work!)
> Colour sets didn't do sync. any differently to monochrome sets - they
> certainly didn't divide down the colour subcarrier, or multiply up to it.
> Yes, the frequency of the subcarrier was _selected_ to have a very precise
> relationship to the line and field pulses, but that was to minimise
> artefacts (such as dot patterns, especially on B/W sets) - sets did not do
> the divisions/multiplications inherent in that selection. (You only have
> to look at what home VCRs did to the colour signals, and sets still worked
> with the output from those!)

When did TV studios stop being synchronised to the mains and start to
synchronise to a crystal? I though it continued well into 240- and 405-line
days, and it was mainly the introduction of colour that prevented it because
anything other than an exact line/frame rate would destroy the careful
f(sub-carrier) = f(line) * (n+1)/2 + 25 Hz relationship, so you'd get
variable dot-patterning which the exact relationship was designed to
minimise.


VCRs (well, VHS anyway) were a lot less tolerant of non-compliant waveforms
than TVs were. My first computer (Transam Wren - CP/M3) had a 625/25 RGB
output for driving an RGB monitor, but had no composite output. Colours
could only be seen as shades of amber on the amber screen that was built in.
So I made a PAL converter, using a PAL encoder IC and a PAL 4.43 MHz crystal
(*). This drove the TV's BNC input and produced fairly good results, subject
to the poor HF response of the average TV and therefore the blurring of fine
horizontal detail. I've no idea whether the timing of the various components
(line/frame rate, front/back porch, equalising pulses) was correct. I never
got chance to try the RGB output on an RGB monitor, but I did try feeding
the composite output through a VCR. Feeding it live (ie PAL input
remodulated onto an RF output) showed noticeable tearing and some shimmering
of colour. Recording and playing back was more amusing: the VCR's head
struggled to sync and colours flickered randomly. Head-sync problems
suggests signal timing errors. Loss of colour and alternating
correct/complementary colour suggests error in PAL frequency.

My PAL decoder was a great idea, and at least on a TV that had baseband
input (BNC or SCART) you could see the colours. The ability to record to
tape was one of those "let's see what happens" experiments rather than
something that was needed. It's a shame that typical PC monitors expected US
TV timings (640x480) or else computer-standard timings for 800x600,
1024x768. I did try the Wren to the monitor on my first IBM-type PC but it
wouldn't sync. No doubt a monitor designed for a BBC Micro would have worked
perfectly - but would have been useless for PC signals.

The ultimate in VCRs producing weird signals was the more recent VHS
machines which were designed for PAL but which could play back a tape that
had been recorded on NTSC. The line/frame rate was 525/30 which some TVs
would sync with, at the expense of a very loud relay clonking as it changed
over, and reduced picture height causing the aspect ratio to be wrong. But
the colour was decoded correctly. Apparently those VCRs were designed to
produce a hybrid output: 525/30 but with pseudo-PAL encoding of colour so a
UK TV would be able to decode it. When I went over to stay with my sister
who was living in the US at the time, I recorded a bit of US TV on their
multi-standard VCR (PAL/NTSC/SECAM) and brought it back to see what my
PAL-only equipment made of it, because I'd heard rumours of partial
compatibility. It was a one-way process: most "modern" PAL VCRs and TVs
could sync with NTSC, but virtually no NTSC equipment could do PAL - an
example of the US "the world stops at America's borders" syndrome ;-) My
sister was warned to buy her multi-standard equipment in the UK before
setting off, because it would not be available for love nor money in the US.



(*) A project in an electronic magazine. I forget whether I had to use
resistors to derive the luminance signal from the correct proportions of
RGB, or whether the IC did that itself. Mains hum was a problem: I found
that I had to drive the circuit from a battery because a supposedly smoothed
PSU caused a lot of ripple in the picture. This was before the days of
switched-mode power supplies everywhere: nowadays a mobile phone charger
that generated USB-compliant power would probably have been fine. A bridge
rectifier with smoothing capacitors was probably not good enough ;-)

[tony sayer]

In article <t7lssj$d5q$1...@dont-email.me>, Woody <harro...@ntlworld.com>
scribeth thus

FWIW the later BW Broadcast FM transmitters have that facility built in
just connect a GPS receiver and you can alter the RF side if need be and
the audio delay, never used it but i have heard in other places like the
states its used and works well!.

Believe it takes the audio and time stamps it so its replayed at the
exact same time on both or more locations.

Some other suppliers have done similar systems, French i think but i
don't think its been used here unless anyone knows different?..

--
Tony Sayer


Man is least himself when he talks in his own person.

Give him a keyboard, and he will reveal himself.

[J. P. Gilliver (John)]

On Tue, 7 Jun 2022 at 13:07:14, NY <m...@privacy.invalid> wrote (my
responses usually FOLLOW):

>"J. P. Gilliver (John)" <G6...@255soft.uk> wrote in message
>news:tXSbS6N7CzniFw+i@a.a...
>>>line frequency affect colour decoding? I presume the PAL crystal in a
>>>TV is nowhere near as tightly controlled as the studio reference
>>
>> True - it is (or was) about the commonest frequency made, but even so
>>cheap crystals can have a tolerance as poor as 500 ppm, but ..
>>
>>>frequency, and PAL has to be able to cope with that, hopefully
>>
>> ... that's what the colour burst at the start of every line is for -
>>to give the local oscillator in the set a frequency, and more
>>important a phase, reference. So the set only needs to hold the
>>reference for one line - 64 μs (less actually because of sync pulse
>>and porches).
>
>The problem comes when the colour is encoded at one frequency and
>decoded at another frequency (because of tolerances in the receiver
>crystals). The colour burst gets the local frequency into the correct
>phase initially, but it the drifts out of phase because the frequency
>is slightly different. And being double-sideband modulation, you don't
>a frequency shift (as with SSB), you get periodic fading. I suppose in
>a really bad case where the frequency difference has a period less than
>a line period, you start to see variations in saturation across each line.
>

Let's do the sums (I haven't until now). 4.43... MHz, with a pretty
grotty crystal - let's say 500 ppm out, which is 0.0005. Hmm, over 2 kHz
out; I didn't think it would be as much as that. (Maybe TV crystals are
better than that; that's just the worst tolerance I can ever remember
seeing quoted for a crystal oscillator.) But assuming that, how far out
could it get in 60 μs (64 less pulse - not sure about porches)? About
one-seventh of a cycle. Yes, I guess that would start to show hue
distortion. Can't say I've ever seen it, though; maybe crystals were
better than that; if they were 100 ppm or better, that gets us down to
about 1/35 - about 10 degrees - which I think wouldn't show. Plus, if
the colour burst gave a shove to frequency as well as phase ... I don't
know if it did (or was even long enough to do so effectively; probably
not).

>
>>>producing saturation rather than hue errors. I realise that before
>>>colour, TVs synced to the mains, so tuners had to cope with a
>>>variation in field rate of 50 +/- 0.5 Hz.
>>
>> I think some Baird Televisors used the mains, but for the frame/field
>>sync., no, that's what the sync pulses are for - even system A ("405"
>>lines) had sync. pulses. (Think about it: how did battery TVs work!)
>>Colour sets didn't do sync. any differently to monochrome sets - they
>>certainly didn't divide down the colour subcarrier, or multiply up to
>>it. Yes, the frequency of the subcarrier was _selected_ to have a
>>very precise relationship to the line and field pulses, but that was
>>to minimise artefacts (such as dot patterns, especially on B/W sets)
>>- sets did not do the divisions/multiplications inherent in that
>>selection. (You only have to look at what home VCRs did to the colour
>>signals, and sets still worked with the output from those!)
>
>When did TV studios stop being synchronised to the mains and start to
>synchronise to a crystal? I though it continued well into 240- and
>405-line days, and it was mainly the introduction of colour that

I think they kept an _eye_ on the relationship, if only to avoid pulsing
when using artificial lighting (even incandescents pulse somewhat), But
I think it was more a matter of nudging the station master oscillator to
avoid that, rather than actually _deriving_ from the mains.

Anyone here know?

>prevented it because anything other than an exact line/frame rate would
>destroy the careful f(sub-carrier) = f(line) * (n+1)/2 + 25 Hz
>relationship, so you'd get variable dot-patterning which the exact
>relationship was designed to minimise.
>

I imagine that relationship was derived by getting both from a master
oscillator, for the reason you describe: if there _was_ any tweaking
done, it would retain the relationship (i. e. the line/frame structure
would be tweaked by the same amount the subcarrier was, so the
relationship would remain fixed).

>
>VCRs (well, VHS anyway) were a lot less tolerant of non-compliant
>waveforms than TVs were. My first computer (Transam Wren - CP/M3) had a
>625/25 RGB output for driving an RGB monitor, but had no composite
>output. Colours could only be seen as shades of amber on the amber
>screen that was built in. So I made a PAL converter, using a PAL
>encoder IC and a PAL 4.43 MHz crystal (*). This drove the TV's BNC
>input and produced fairly good results, subject to the poor HF response
>of the average TV and therefore the blurring of fine horizontal detail.
>I've no idea whether the timing of the various components (line/frame
>rate, front/back porch, equalising pulses) was correct. I never got
>chance to try the RGB output on an RGB monitor, but I did try feeding
>the composite output through a VCR. Feeding it live (ie PAL input
>remodulated onto an RF output) showed noticeable tearing and some
>shimmering of colour. Recording and playing back was more amusing: the
>VCR's head struggled to sync and colours flickered randomly. Head-sync
>problems suggests signal timing errors. Loss of colour and alternating
>correct/complementary colour suggests error in PAL frequency.

I'm not surprised at the colour problems, given the number of stages the
colour (difference) signal went through in a domestic VCR. I'm a bit
surprised at the head sync problems; I'd have _thought_ a computer would
generate more precise video than, say, many video cameras of the era (it
wasn't unknown for them to use two completely independent and not
connected oscillators for line and field/frame!). If the head was
"motorboating" that probably didn't help the colour timing either.

>
>My PAL decoder was a great idea, and at least on a TV that had baseband

encoder (-:

>input (BNC or SCART) you could see the colours. The ability to record
>to tape was one of those "let's see what happens" experiments rather
>than something that was needed. It's a shame that typical PC monitors
>expected US TV timings (640x480) or else computer-standard timings for
>800x600, 1024x768. I did try the Wren to the monitor on my first
>IBM-type PC but it wouldn't sync. No doubt a monitor designed for a BBC
>Micro would have worked perfectly - but would have been useless for PC
>signals.

At the standard resolutions, yes. Some of the graphics cards of those
days (I don't know if still) could be directly programmed in terms of
frequencies - I did meet one 405-line enthusiast who, rather than use
one of the converter boxes popular at the time (and maybe still) among
that fraternity, generated a system A signal direct from her computer (I
think from Linux). But yes, DOS and Windows probably only put out the US
TV standard at the time. (I wonder if it was even interlaced.)

>
>The ultimate in VCRs producing weird signals was the more recent VHS
>machines which were designed for PAL but which could play back a tape
>that had been recorded on NTSC. The line/frame rate was 525/30 which
>some TVs would sync with, at the expense of a very loud relay clonking
>as it changed over, and reduced picture height causing the aspect ratio
>to be wrong. But the colour was decoded correctly. Apparently those
>VCRs were designed to produce a hybrid output: 525/30 but with
>pseudo-PAL encoding of colour so a UK TV would be able to decode it. When I

Or PAL-M as I think it was called (and I think Brazil and possibly a few
others even broadcast it).

It confused some sets, too: some had a (presumably crude was more than
sufficient) line/field rate detector, and if they received 525/60,
assumed they were getting NTSC, and switched the colour accordingly - so
if you fed them 525/60 PAL, they didn't decode it!

(I presume the 525/60 PAL those machined produced used the 4.43...
subcarrier European PAL sets were expecting, so the careful calculations
re avoiding dot crawl/patterning didn't work.)

>went over to stay with my sister who was living in the US at the time,
>I recorded a bit of US TV on their multi-standard VCR (PAL/NTSC/SECAM)
>and brought it back to see what my PAL-only equipment made of it,
>because I'd heard rumours of partial compatibility. It was a one-way
>process: most "modern" PAL VCRs and TVs could sync with NTSC, but
>virtually no NTSC equipment could do PAL - an example of the US "the
>world stops at America's borders" syndrome ;-) My sister was warned to

Like the "World Series" baseball (is it? Or American football? I don't
follow either).

>buy her multi-standard equipment in the UK before setting off, because
>it would not be available for love nor money in the US.
>

At least things have improved slightly since then: I don't know how
compatible digital TV standards are between US and Europe, but now at
least in Folkestone the odd time I can get French TV, it decodes fine,
whereas previously even ignoring the PAL/SECAM question, the different
sound separation means I couldn't get both sound and vision. (I do
remember back in the day displaying their 819-line on a 405 set though!
Just a curiosity - no sound and you got two tall thin side-by-side
pictures.)

>
>
>(*) A project in an electronic magazine. I forget whether I had to use
>resistors to derive the luminance signal from the correct proportions
>of RGB, or whether the IC did that itself. Mains hum was a problem: I
>found that I had to drive the circuit from a battery because a
>supposedly smoothed PSU caused a lot of ripple in the picture. This was
>before the days of switched-mode power supplies everywhere: nowadays a
>mobile phone charger that generated USB-compliant power would probably
>have been fine. A bridge rectifier with smoothing capacitors was
>probably not good enough ;-)

Yes, "smoothed" still has _some_ ripple. A linear regulator might have
helped - the ubiquitous 78 series in those days, probably.

--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

"If god doesn't like the way I live, Let him tell me, not you." - unknown

[Roderick Stewart]

On Tue, 7 Jun 2022 12:04:27 +0100, "J. P. Gilliver (John)"
<G6...@255soft.uk> wrote:

>I think some Baird Televisors used the mains, but for the frame/field
>sync., no, that's what the sync pulses are for - even system A ("405"
>lines) had sync. pulses. (Think about it: how did battery TVs work!)

As far as I know, the Baird 30 line system didn't include sync pulses
at all, so there would have been no other way to synchronise the motor
than either to use the mains or derive a signal from picture content.

Shot changes were accomplished by someone holding a board with a
checkerboard pattern in front of the camera (or scanner, as they
called it) which couldn't be moved of course because that would have
disturbed the rotation of the disc. A checkerboard was used instead of
a "fade to black" in order to ensure that there was always some
picture content of some sort, so presumably they expected some
receivers to use this.

Baird did experiment with mechanical spinning disc systems with
greater numbers of lines, but I don't know if any of them included
sync pulses.

Rod.

[Paul Ratcliffe]

On Mon, 6 Jun 2022 22:51:15 +0100, Woody <harro...@ntlworld.com> wrote:

> When I used to do quasi-sync radio system setups (by the bucket load!)
> I used the free space signal propagation time as 5.38uS per mile, so 70Km
> would give about 234uS.

That's "us" and "km" rather than "uS" and "Km".


(No units were harmed in the making of this message.)

[Liz Tuddenham]

Roderick Stewart <rj...@escapetime.myzen.co.uk> wrote:


> Baird did experiment with mechanical spinning disc systems with
> greater numbers of lines, but I don't know if any of them included
> sync pulses.

I think the 'high definition' 120-line system used blacker-than-black
sync pulses. The specs of the Baird and the EMI system were published
in Wireless World at the time, but it might be difficult to track down
which issue they appeared in.

--
~ Liz Tuddenham ~
(Remove the ".invalid"s and add ".co.uk" to reply)
www.poppyrecords.co.uk

[J. P. Gilliver (John)]

On Tue, 7 Jun 2022 at 17:56:08, Paul Ratcliffe
<ab...@orac12.clara34.co56.uk78> wrote (my responses usually FOLLOW):

Or even μs (-:

--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

The death of democracy is not likely to be an assassination from ambush.
It will be a slow extinction from apathy, indifference, and undernourishment.
-Robert Maynard Hutchins, educator (1899-1977)

[J. P. Gilliver (John)]

On Tue, 7 Jun 2022 at 18:46:36, Roderick Stewart
<rj...@escapetime.myzen.co.uk> wrote (my responses usually FOLLOW):
[]

>Shot changes were accomplished by someone holding a board with a
>checkerboard pattern in front of the camera (or scanner, as they
>called it) which couldn't be moved of course because that would have
>disturbed the rotation of the disc. A checkerboard was used instead of

[]
I'm not sure the spinning-disc thing was referred to as a scanner. The
one that used a lot (well, presumably 30) of mirrors on a drum, mainly
used for outside broadcasts (most famously of the Derby), was - and (we
had a discussion about this a year two ago) - seems to be the most
plausible reason why OB vehicles themselves acquired that name. (Other
suggestions were their resemblance to mobile radar vans, or that it
contained the master sync. ["scanning waveform"] generators for OB
cameras; both seemed ruled out as there is some evidence of the term for
the vehicle predating the existence of both of those.)

--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

[Paul Ratcliffe]

On Tue, 7 Jun 2022 23:37:36 +0100, J. P. Gilliver (John) <G6...@255soft.uk>

wrote:

>>> When I used to do quasi-sync radio system setups (by the bucket load!)
>>> I used the free space signal propagation time as 5.38uS per mile, so 70Km
>>> would give about 234uS.
>>
>>That's "us" and "km" rather than "uS" and "Km".
>>
>>
>>(No units were harmed in the making of this message.)
>>

> Or even ??s (-:

My reader only does ASCII.

[Tweed]

Time to modernise?

[Roderick Stewart]

On Tue, 7 Jun 2022 23:36:43 +0100, "J. P. Gilliver (John)"
<G6...@255soft.uk> wrote:

>>Shot changes were accomplished by someone holding a board with a
>>checkerboard pattern in front of the camera (or scanner, as they
>>called it) which couldn't be moved of course because that would have
>>disturbed the rotation of the disc. A checkerboard was used instead of
>[]
>I'm not sure the spinning-disc thing was referred to as a scanner. The
>one that used a lot (well, presumably 30) of mirrors on a drum, mainly
>used for outside broadcasts (most famously of the Derby), was - and (we
>had a discussion about this a year two ago) - seems to be the most
>plausible reason why OB vehicles themselves acquired that name. (Other
>suggestions were their resemblance to mobile radar vans, or that it
>contained the master sync. ["scanning waveform"] generators for OB
>cameras; both seemed ruled out as there is some evidence of the term for
>the vehicle predating the existence of both of those.)

So what do you think they did call it then?

Rod.

[Andy Burns]

Paul Ratcliffe wrote:

> My reader only does ASCII.

put

charset display utf8
charset outgoing utf8

in ~/.slrnrc

[J. P. Gilliver (John)]

On Wed, 8 Jun 2022 at 08:05:26, Roderick Stewart

<rj...@escapetime.myzen.co.uk> wrote (my responses usually FOLLOW):

>On Tue, 7 Jun 2022 23:36:43 +0100, "J. P. Gilliver (John)"
><G6...@255soft.uk> wrote:
>
>>>Shot changes were accomplished by someone holding a board with a
>>>checkerboard pattern in front of the camera (or scanner, as they
>>>called it) which couldn't be moved of course because that would have
>>>disturbed the rotation of the disc. A checkerboard was used instead of
>>[]
>>I'm not sure the spinning-disc thing was referred to as a scanner. The
>>one that used a lot (well, presumably 30) of mirrors on a drum, mainly
>>used for outside broadcasts (most famously of the Derby), was - and (we

[]

>So what do you think they did call it then?

Camera maybe?
>
>Rod.

--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

... she has never contracted A-listeria or developed airs and graces. Kathy
Lette on Kylie, RT 2014/1/11-17

[J. P. Gilliver (John)]

On Wed, 8 Jun 2022 at 05:58:30, Tweed <usenet...@gmail.com> wrote (my
responses usually FOLLOW):

Andy Burns' suggestion may help - sounds like he knows which reader you
are using.

Probably my fault - Turnpike lets me use non-ASCII characters, but
doesn't put the magic spell in the subject line (or maybe in the
headers?) that is maybe needed when I do so.

Interestingly, I generated the mu with Alt-230 (note no leading 0) - μ
- which I remembered from yonks ago, rather than Alt-0181 μ that is
more commonly used. Normally when I post or email with non-ASCII,
Turnpike warns me, but I think it didn't this time. Let me see this time
... hmm, it did, and highlighted the first one, so maybe it did after
all.

--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

[Stephen Wolstenholme]

I only post or read ASCII as I don't like pictures advertising
rubbish.

--
Neural Network Software for Windows http://www.npsnn.com

[John Williamson]

On 08/06/2022 13:01, Stephen Wolstenholme wrote:

> I only post or read ASCII as I don't like pictures advertising
> rubbish.
>

Which version of ASCII does sir prefer?

ASA X3.4-1963
ASA X3.4-1965 (approved, but not published, nevertheless used by IBM
2260 & 2265 Display Stations and IBM 2848 Display Control)
USAS X3.4-1967
USAS X3.4-1968
ANSI X3.4-1977?

Others are also out there and approved.

https://en.wikipedia.org/wiki/ASCII

--
Tciao for Now!

John.

[Andy Burns]

Stephen Wolstenholme wrote:

> Paul Ratcliffe wrote:
>
>> My reader only does ASCII.
>
> I only post or read ASCII as I don't like pictures advertising
> rubbish.

.___ .__ __ __________________________________________
__| _/______|__| ____ | | __ \______ \_ _____/\_ _____/\______ \
/ __ |\_ __ \ |/ \| |/ / | | _/| __)_ | __)_ | _/
/ /_/ | | | \/ | | \ < | | \| \ | \ | | \
\____ | |__| |__|___| /__|_ \ |______ /_______ //_______ / |____|_ /
\/ \/ \/ \/ \/ \/ \/
__ ________________ __________ _________
______ _____ ____ | | __ ____ \__ ___/ _ \\______ \/ _____/
/ ___// \ / _ \| |/ // __ \ | | / /_\ \| | _/\_____ \
\___ \| Y Y ( <_> ) <\ ___/ | |/ | \ | \/ \
/____ >__|_| /\____/|__|_ \\___ > |____|\____|__ /______ /_______ /
\/ \/ \/ \/ \/ \/ \/

[st...@swingnn.com]

On Wed, 8 Jun 2022 13:12:34 +0100, John Williamson
<johnwil...@btinternet.com> wrote:

>On 08/06/2022 13:01, Stephen Wolstenholme wrote:
>
>> I only post or read ASCII as I don't like pictures advertising
>> rubbish.
>>
>Which version of ASCII does sir prefer?

Plain text, whatever it's number was.

When did I get knighted? I must have missed HRH with a sword.

Steve

--
Neural Network Software http://www.npsnn.com
JustNN Just a neural network http://www.justnn.com
EasyNN-plus More than just a neural network http://www.easynn.com
SwingNN Prediction software http://www.swingnn.com

[John Williamson]

On 08/06/2022 13:31, st...@swingnn.com wrote:
> On Wed, 8 Jun 2022 13:12:34 +0100, John Williamson
> <johnwil...@btinternet.com> wrote:
>
>> On 08/06/2022 13:01, Stephen Wolstenholme wrote:
>>
>>> I only post or read ASCII as I don't like pictures advertising
>>> rubbish.
>>>
>> Which version of ASCII does sir prefer?
>
> Plain text, whatever it's number was.
>

All the ones mentioned are plain text. All are slightly different, and
there are and were many versions of each in use, depending where in the
world you are.

Unless you are referring to the earliest 7-bit version, and even that
was not universal.

[Stephen Wolstenholme]

On Wed, 8 Jun 2022 13:44:01 +0100, John Williamson

<johnwil...@btinternet.com> wrote:

>On 08/06/2022 13:31, st...@swingnn.com wrote:
>> On Wed, 8 Jun 2022 13:12:34 +0100, John Williamson
>> <johnwil...@btinternet.com> wrote:
>>
>>> On 08/06/2022 13:01, Stephen Wolstenholme wrote:
>>>
>>>> I only post or read ASCII as I don't like pictures advertising
>>>> rubbish.
>>>>
>>> Which version of ASCII does sir prefer?
>>
>> Plain text, whatever it's number was.
>>
>All the ones mentioned are plain text. All are slightly different, and
>there are and were many versions of each in use, depending where in the
>world you are.
>
>Unless you are referring to the earliest 7-bit version, and even that
>was not universal.

I suppose I should be saying that I use whatever is on my keyboard. My
current Samsung R720 laptop has the same qwerty layout as my
typewriter had about 60 years ago. My typewriter did not use ASCII. In
fact it didn't use electricity. I must get it from the shed as it may
be worth something!

Steve
--
Neural Network Software for Windows http://www.npsnn.com

[BrightsideS9]

Mabe worth nowt, like mine, cannot get ribbons for it.

--
brightside s9

[NY]

"Andy Burns" <use...@andyburns.uk> wrote in message
news:jgbigf...@mid.individual.net...

Even when I copied that to a text editor with a fixed-pitch font, it was not
easy to ready. But I deciphered it eventually. I'll go for the first one,
but I'll steer clear of the second as I hate the smell of cigarette smoke
;-)

[Stephen Wolstenholme]

On Wed, 08 Jun 2022 15:01:11 +0100, BrightsideS9
<reply_to_ad...@invalid.invalid> wrote:

>
>Mabe worth nowt, like mine, cannot get ribbons for it.

Bring back carbon paper!

[Andy Burns]

NY wrote:

> Andy Burns wrote:
>
>>     .___      .__        __     __________________________________________
>>   __| _/______|__| ____ |  | __ \______   \_   _____/\_   _____/\______ \
>>  / __ |\_  __ \  |/    \|  |/ /  |    |  _/|    __)_  |    __)_  | _/
>> / /_/ | |  | \/  |   |  \    <   |    |   \|        \ |        \ |    | \
>> \____ | |__|  |__|___|  /__|_ \  |______  /_______  //_______  / |____|_ /
>>      \/               \/     \/         \/        \/         \/         \/
>>                        __            ________________ __________ _________
>>   ______ _____   ____ |  | __ ____   \__    ___/  _  \\______   \/ _____/
>>  /  ___//     \ /  _ \|  |/ // __ \    |    | /  /_\  \|    |  _/\_____  \
>>  \___ \|  Y Y  (  <_> )    <\  ___/    |    |/    |    \    |   \/ \
>> /____  >__|_|  /\____/|__|_ \\___  >   |____|\____|__  /______  /_______ /
>>      \/      \/            \/    \/                  \/       \/        \/
>
> Even when I copied that to a text editor with a fixed-pitch font, it was not
> easy to ready. But I deciphered it eventually. I'll go for the first one, but
> I'll steer clear of the second as I hate the smell of cigarette smoke ;-)

Not a Viz fan?

[joe bloggs]

A lot to consider here!

First off the comment about the time required for the picture on one tuned viewed signal to roll acrossthe second tuned signal. As Mark Carver has already posted the accuracy of the (individual) broadcasters SPG signals were very tightly defined by the various specs and under normal circumstances you would not expect anything like the figures quoted by the OP. A figure of about a minute for one picture to roll across another one just defies rational explanation as you would expect the 'rolling' through to be pretty much undetectable to the human eye.

Different sound delays on various paths. I think this is being overthought, certainly in terms of ITV. MC has eluded to the likely cause and that is the widespread use of framestores by the individual ITV companies at the time. Each ITV station would have its own SPG's and although they would naturally be within the agreed spec there is every reason to suggest that each company's SPG would be at a different 'place in time and space' when compared other ITV companies - hence the need to use a frame stores. Consider the following typical scenario. Granada is playing out Coronation Street using its own station SPG. Let us say that its SPG is running at Fgr (in time and space). The programme is being fed to Thames and TVS and they are each using their own SPGs to synchronise the Granada programme to their station. But Thames' and TVS' local SPGs are at different places in 'time and space' to each other - let us call them Fth and Ftvs and the only common thing is the timing of the Granada programme running at Fg into both Thames and TVS. So Thames' and TVS' frame stores have to introduce different delays to the remote incoming programme from Granada to make it synchronous to their own free running local SPG's. The time difference, or delay if you like, across Thames' and TVS's synchronisers will be different as their local SPGs are completely independent and free running. Like all the other ITV companies Thames' and TVS' SPGs could be quite close (fluke) or fields apart, but they would both still be running perfectly in spec.

Here's the obvious catch, if you are delaying a programme through a framestore you are also delaying the picture with respect to the sound (which did not pass through a framestore). To make this correct again you had an audio delay in line with the audio. Typically these audio delays would have two reference video inputs too, one video input was the incoming 'raw' undelayed video (Fgr) and the other would be the output of the local SPG feeding the framestore (now either Ft or Ftvs). The audio delay unit would measure the difference between the two reference signals and drop in a matching delay in the audio path. You can see now that Coronation Street is extremely likely to be in a different place 'in time and space' from one ITV company to another so if you are in a position to listen to the output of both companies at the same time it is very likely their will be a difference in audio timing between the two sources.

It was a long time ago, but Fsc is actually (Fline *283.75) + 25 hz. The additional .75 is/was vital to reduce cross colour interference between the luma and chroma signals.

[charles]

In article <c5c1ah9g23mri7deh...@4ax.com>,

Stephen Wolstenholme <st...@easynn.com> wrote:
> On Wed, 08 Jun 2022 15:01:11 +0100, BrightsideS9
> <reply_to_ad...@invalid.invalid> wrote:

> >
> >Mabe worth nowt, like mine, cannot get ribbons for it.

> Bring back carbon paper!

> Steve

I've still got some ;-)

--
from KT24 in Surrey, England
"I'd rather die of exhaustion than die of boredom" Thomas Carlyle

[Max Demian]

Apparently the original idea was that the code for $ would show the
local currency symbol, wherever you are. Which would have been confusing.

--
Max Demian

[John Williamson]

The beauty of computing standards is that there have always been so many
to choose frpm...

[NY]

"joe bloggs" <reel.sounds.of...@gmail.com> wrote in message
news:92902d13-264f-4f90...@googlegroups.com...

> Here's the obvious catch, if you are delaying a programme through a
> framestore you are also delaying the picture with respect to the sound
> (which did not pass through a framestore). To make this correct again you
> had an audio delay in line with the audio. Typically these audio delays
> would have two reference video inputs too, one video input was the
> incoming 'raw' undelayed video (Fgr) and the other would be the output of
> the local SPG feeding the framestore (now either Ft or Ftvs). The audio
> delay unit would measure the difference between the two reference signals
> and drop in a matching delay in the audio path. You can see now that
> Coronation Street is extremely likely to be in a different place 'in time
> and space' from one ITV company to another so if you are in a position to
> listen to the output of both companies at the same time it is very likely
> their will be a difference in audio timing between the two sources.

Ah, did/does the design of frame stores and SPGs not include an equivalent
delay for the sound and, nowadays, any other data streams such as subtitles?

[NY]

"John Williamson" <johnwil...@btinternet.com> wrote in message
news:jgc41e...@mid.individual.net...

> to choose from...

And you can always rely on Apple to ignore *all* the standards and invent
their own incompatible ones.

[joe bloggs]

I'm not sure I understand your query. In the days of analogue, framestores were designed to synchronise remote video sources to your local video sources. They were not designed to deal with audio - that is why separate audio delay units were required. The delay through the framestore and its associated audio delay unit obviously depended on the timing difference between the incoming video and your local SPG - this would be variable as the two elements were always 'moving' with respect to one another. And of course as programmes were switched around the ITV network between different companies as the day progressed so the delay varied willy nilly as it were. I cannot speak about 'nowadays' I'm afraid as I have no knowledge.

[J. P. Gilliver (John)]

On Wed, 8 Jun 2022 at 21:28:56, NY <m...@privacy.invalid> wrote (my
responses usually FOLLOW):

Apple and Microsoft at least - probably other companies too. (The
"caribou" quote has always IME specified Microsoft.)


A _few_ companies tried to adhere to standards; sadly, this was often to
their detriment, as the non-standard practice of others (IMO often
Microsoft) became the _de facto_ standard, and they were _seen_ as being
different. Turnpike for example. In a slightly earlier era, Acorn-as-BBC
used to be quite compliant, but I think they were quite close to the
standards generation anyway.

[Mark Carver]

There's so much use of different circuits, different codecs, different
and diverse routing, all manner of things can and do happen, but broadly
'lip sync' being out (and seriously out) is far more common and easily
achievable this century than in the  last !

[John Williamson]

On 09/06/2022 10:05, Mark Carver wrote:

> 'lip sync' being out (and seriously out) is far more common and easily
> achievable this century than in the last !

A classic example was watching the Mamma Mia cast at the platinum
jubilee concert. It was either bad delay settings or really bad miming.

[Mark Carver]

I gather it was a bit of both, the latter being due to the performers
not being able to hear the foldback properly. Quite a few were seen
ripping out their earpieces.

There was no opportunity for any proper sound check or rehearsal (unlike
a conventional outdoor gig)

[Paul Ratcliffe]

It doesn't help. The thing just beeps at me now saying it can't convert
utf-8 -> utf8.
So I looked up the documentation about valid character set names and
nothing was listed, and it only says utf8 etc. in the slrn.rc file - so that's
f* useless.
I tried putting utf-8 instead of utf8 and that stopped it beeping, but the
?? just got displayed as two other characters - I presume the equivalent
of the utf8 codes in some other codepage, but which one I know not (probably
ibm850 but ICBA...).

And then your editor has to support it, which it does, but only if there's
a BOM at the start of the file to tell it... and there isn't, so it doesn't.

At which point you think, why did I f'ing bother with all this crap which
doesn't work properly. So I put it back.
And I don't have a "mu" key on my keyboard to type it anyway, so there's yet
another hassle.

Usenet was designed to be 7 bit, so operate it in 7 bit I damned well will.
"u" has long been used for "mu" in all sorts of places.

[Paul Ratcliffe]

On Wed, 8 Jun 2022 11:08:54 +0100, J. P. Gilliver (John) <G6...@255soft.uk>
wrote:

> Andy Burns' suggestion may help - sounds like he knows which reader you
> are using.

It's in the headers.

> Probably my fault - Turnpike lets me use non-ASCII characters, but
> doesn't put the magic spell in the subject line (or maybe in the
> headers?) that is maybe needed when I do so.

It did put it in the headers.

> Interestingly, I generated the mu with Alt-230 (note no leading 0) - ??
> - which I remembered from yonks ago, rather than Alt-0181 ??

You see, here is exactly the problem.
Quoting random numbers without defining the codepage they come from is
completely and utterly pointless.
And this Alt-xxx business is platform specific to Windows. Try doing it
or the equivalent in a Linux shell (and I have, and failed).

[Paul Ratcliffe]

On Wed, 8 Jun 2022 05:58:30 -0000 (UTC), Tweed <usenet...@gmail.com> wrote:

>>> Or even ??s (-:

>>
>> My reader only does ASCII.
>>
>

> Time to modernise?

To what? And why?

[Paul Ratcliffe]

On Wed, 08 Jun 2022 13:31:20 +0100, st...@swingnn.com <st...@swingnn.com>
wrote:

>>Which version of ASCII does sir prefer?
>
> Plain text, whatever it's number was.
>
> When did I get knighted? I must have missed HRH with a sword.

I think that would have been "Sir" rather than "sir", so nobody's missed
your neck with a knife... yet.

[Paul Ratcliffe]

On Wed, 08 Jun 2022 14:52:55 +0100, Stephen Wolstenholme <st...@easynn.com>
wrote:

> My typewriter did not use ASCII. In fact it didn't use electricity.
> I must get it from the shed as it may be worth something!

It's probably corroded to buggery if it's been in a shed.

Mother's manual is still in a wardrobe - last time I looked it was still
in good nick. Hasn't been used for well over 40 years of course, and
probably last by me.

[NY]

"Paul Ratcliffe" <ab...@orac12.clara34.co56.uk78> wrote in message
news:slrnta4vpp...@news.pr.network...

In the 1970s my dad acquired a *very* typewriter - he might have been loaned
it for a few years by someone at work. It was unusual in having two sets of
letter keys - one for lower-case and one for upper-case, rather than the
normal arrangement of a single set of keys which can be shifted between
cases, with each type bar having both letters on it. It was also unusual in
that it had all the digits - except 1 for which I presume you were expected
to use upper-case I or lower-case L. I can remember the keys: they were
octagonal and one set was cream and the other was almost-black. It was
*very* heavy: I imagine the frame of it was made of cast iron.

It looked similar to this one
https://twitter.com/ns_moi/status/1303597508103491586.

[Brian Gaff]

For some odd reason, a few messages back the subject line vanished from this
thread can anyone else see this, or in this case, not see it?
Brian

--

--:
This newsgroup posting comes to you directly from...
The Sofa of Brian Gaff...
bri...@blueyonder.co.uk
Blind user, so no pictures please
Note this Signature is meaningless.!
"Mark Carver" <mark....@invalid.invalid> wrote in message
news:jgdsgb...@mid.individual.net...

[NY]

The subject line still reads "Re: Satellite multiplex 11307H - copy of
Freeview PSB2 Bilsdale" for me, both on Windows Live Mail via Eternal
September news server and on Thunderbird via Plusnet server.

I wonder if it has mutated somehow in a way that is preventing your screen
reader software being able to interpret it.

"Brian Gaff" <brian...@gmail.com> wrote in message
news:t7v41s$aeb$1...@dont-email.me...

[Brian Gaff]

Yes it changes a few messages back t just a blank. Its probably got a
character in it that is not catered for in my current settings.

That forces it to a new character set and if the reader does not support it
it just leaves it blank.
I sometimes wish all the youngsters could have permanent imogees off
switch.
Brian

"NY" <m...@privacy.invalid> wrote in message
news:t7vigd$l42$1...@dont-email.me...

[J. P. Gilliver (John)]

On Fri, 10 Jun 2022 at 15:46:02, Brian Gaff <brian...@gmail.com> wrote
(my responses usually FOLLOW):

>Yes it changes a few messages back t just a blank. Its probably got a
>character in it that is not catered for in my current settings.

It's still there as I see it, even in your posting.

>
>That forces it to a new character set and if the reader does not support it
>it just leaves it blank.
> I sometimes wish all the youngsters could have permanent imogees off
>switch.

[]
Sometimes it would be easier if the youngsters just had an off switch.
\\
They probably think the same about us, too (-:

--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

Who is Art, and why does life imitate him?

[Brian Gaff]

Hmm, I've had a look at the message source and there is nothing special
about the subject line, so who knows.

Brian

--

--:
This newsgroup posting comes to you directly from...
The Sofa of Brian Gaff...
bri...@blueyonder.co.uk
Blind user, so no pictures please
Note this Signature is meaningless.!

"NY" <m...@privacy.invalid> wrote in message
news:t7vigd$l42$1...@dont-email.me...

[J. P. Gilliver (John)]

On Thu, 9 Jun 2022 at 23:06:00, Paul Ratcliffe
<ab...@orac12.clara34.co56.uk78> wrote (my responses usually FOLLOW):
[]

>Usenet was designed to be 7 bit, so operate it in 7 bit I damned well will.

(-:

>"u" has long been used for "mu" in all sorts of places.

Or occasionally U (mainly on those big electrolytics).

M for m is intellectually irritating, but usually not confusing in
context - there aren't many megafarads about, and that little transistor
radio I had in the 1970s (quite unusual for those days - ran on a single
AA cell; I presume it was germanium rather than silicon circuitry
[certainly wasn't switched-mode! Very simple tranny, one knob for tuning
one for volume, MW only]) I knew didn't really have 65-75 megawatts of
audio output power, despite what the instruction leaflet said.

[Brian Gaff]

test to see if sub line comes back.

Please ignore

Brian


--

--:
This newsgroup posting comes to you directly from...
The Sofa of Brian Gaff...
bri...@blueyonder.co.uk
Blind user, so no pictures please
Note this Signature is meaningless.!

"joe bloggs" <reel.sounds.of...@gmail.com> wrote in message

news:a781d0fa-74d5-4413...@googlegroups.com...

[Brian Gaff]

No I suspect their might ave been a grees symbol in the original and I know
under the current windows settings on this client, that character is not
accepted any more than the pound sign is.

At least not in the sub line £

Brian


--

--:
This newsgroup posting comes to you directly from...
The Sofa of Brian Gaff...
bri...@blueyonder.co.uk
Blind user, so no pictures please
Note this Signature is meaningless.!

"Brian Gaff" <brian...@gmail.com> wrote in message

news:t7vov2$s5q$1...@dont-email.me...

[John Williamson]

On 10/06/2022 16:27, J. P. Gilliver (John) wrote:
> On Fri, 10 Jun 2022 at 15:46:02, Brian Gaff <brian...@gmail.com> wrote
> (my responses usually FOLLOW):
>> Yes it changes a few messages back t just a blank. Its probably got a
>> character in it that is not catered for in my current settings.
>
> It's still there as I see it, even in your posting.
>>
>> That forces it to a new character set and if the reader does not
>> support it
>> it just leaves it blank.
>> I sometimes wish all the youngsters could have permanent imogees off
>> switch.
> []
> Sometimes it would be easier if the youngsters just had an off switch.
> \\
> They probably think the same about us, too (-:

To be honest, Brian Gaff is using an e-mail program and news reader
that ran out of support and was replaced in 2009, but was not 100%
standards compliant even then.

That and his screen reader would probably explain the problems he keeps
reporting. Time to update, I reckon. It will be a pain, but once he
learns the new set of shortcuts, or somebody sighted modifies the
defaults to suit the way he likes to work, most of the problems will go
away.

[NY]

"John Williamson" <johnwil...@btinternet.com> wrote in message

news:jghe7q...@mid.individual.net...

I cannot comment or criticise because I'm still using Windows Live Mail from
2009.

Given the recent authentication changes to Gmail, I'm wondering whether to
stay with WLM and enable 2-factor-authorisation so I can create the
app-specific password that Gmail over POP now needs, or whether to bite the
bullet and work out how to transfer all my old saved-email folders and email
accounts to Thunderbird which supports the OAuth2 authentication that Gmail
would prefer people to use.

Shame that Microsoft didn't produce a "son of WLM" for Windows 8 and 10, and
instead wasted their efforts on the toy "Mail" application which is bundled
with those versions and which is so cut-down as to be neither use nor
ornament, as we say in Yorkshire.

[williamwright]

On 10/06/2022 22:09, NY wrote:
> neither use nor ornament

Useful for describing employees.

Bill

[John Williamson]

On 10/06/2022 22:09, NY wrote:

I've been using Thunderbird since version 2.summat. All my e-mail is
still accessible, no matter what format it was sent in, and unless they
get mangled by a non-compliant reader, I have no trouble reading any
usenet posts. The on;y exception I have had problems with was someone
who insisted on sending e-mail attachments using Outlook's own non
standard wrapper, but there's a plugin for that.

By the way, if I ever feel the need to transfer to Linux, TB there uses
the same data format as TB on Windows, so my mailboxes appear exactly as
they do in Windows, and I have, in the past, used the same mailbox files
on both boot OS's in a dual boot machine. TB can even be used on MacOS,
though not, as of now, on Android. (There is a project under way.)

> Given the recent authentication changes to Gmail, I'm wondering whether
> to stay with WLM and enable 2-factor-authorisation so I can create the
> app-specific password that Gmail over POP now needs, or whether to bite
> the bullet and work out how to transfer all my old saved-email folders
> and email accounts to Thunderbird which supports the OAuth2
> authentication that Gmail would prefer people to use.
>

Gmail's 0Auth2 can be handled using Thunderbird fairly easily, and the
transfer is a trivial problem.

> Shame that Microsoft didn't produce a "son of WLM" for Windows 8 and 10,
> and instead wasted their efforts on the toy "Mail" application which is
> bundled with those versions and which is so cut-down as to be neither
> use nor ornament, as we say in Yorkshire.

Micro$oft want everyone to use Office 365, which has a decent feature
set, but makes it difficult to keep your data private.

[NY]

"John Williamson" <johnwil...@btinternet.com> wrote in message

news:jgj3ph...@mid.individual.net...

>> Shame that Microsoft didn't produce a "son of WLM" for Windows 8 and 10,
>> and instead wasted their efforts on the toy "Mail" application which is
>> bundled with those versions and which is so cut-down as to be neither
>> use nor ornament, as we say in Yorkshire.
>
> Micro$oft want everyone to use Office 365, which has a decent feature set,
> but makes it difficult to keep your data private.

Outlook (the email part of Office 365) has a very rich feature set, with
lots of features that are more use in office environments (scheduling
meetings etc). But it is painful to configure and diagnose.

The three main design problems I've encountered are:

- All the email folders and messages within them are stored in a single
humungous .pst file. When you back up your emails periodically, you have to
rewrite this whole multi-GB file, even though only one message has been
added/changed. Thunderbird (like the old MS Outlook Express) uses one file
per email folder, so you only have to backup that folder. Windows Live Mail
uses one file per message which is even more efficient because you only have
to backup the files that correspond to new/changed messages.

- Trying to get diagnostics about why a POP/SMTP connection is failing is
more difficult. I think the transfer is done asynchronously (set it running
and then lose control of it) so it's harder to abort a transfer that has
hung.

- There isn't a way of backing up the definition of each email connection
(servers, ports, usernames/passwords) into a .iaf file as there is for
Outlook Express (XP) / Windows Mail (Vista) / Windows Live Mail (Win 7),
which makes it very difficult to copy an email setup to a new PC, because
you have to remember the passwords and copy all the other settings manually.

Outlook also suffers from having all these features - except one important
one: it does not have a news reader :-(


There is another problem: Outlook costs money, whereas OE/WM/WLM/Thunderbird
are free ;-)

[J. P. Gilliver (John)]

On Sat, 11 Jun 2022 at 12:09:43, NY <m...@privacy.invalid> wrote (my
responses usually FOLLOW):
[]

>Outlook also suffers from having all these features - except one
>important one: it does not have a news reader :-(
>

It _sort of_ did up to - I'm not sure, might have been 2003 or the
version before that (it became academic as they turned off our internal
news servers): it just used msimn (i. e. OE), but provided a wrapper
interface, so it _looked_ as if you were using news from inside Outlook.
(I remember we had to be careful what we said when contacting [internal]
support if there was a problem, as they'd been told they didn't support
[something - I forget what]; they did, but you had to phrase what you
asked them carefully.)

>
>There is another problem: Outlook costs money, whereas
>OE/WM/WLM/Thunderbird are free ;-)

Messybeast used Outlook, I think finding its other functions - and I'm
guessing the support - worth paying for.

--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

Someone once said that scientists and prostitutes get paid for doing what they
enjoy. - Prof Stepehen Hawking in RT 2013/12/7-13