Digital set-top boxes (slightly O/T) - weak signal area.

Page 6 of 8  
On 18 Jan 2004 18:23:53 GMT, snipped-for-privacy@ukmisc.org.uk (Huge) wrote:

Sorry, didn't realise you were pedantic.
PoP
Sending email to my published email address isn't guaranteed to reach me.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Funny way of spelling "correct".
Computers are like Old Testament Gods; Lots of rules and no mercy.
--
"The road to Paradise is through Intercourse."
[email me at huge [at] huge [dot] org [dot] uk]
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
wrote:

I think you mean assembler.

So, a powerful language that you have to know what you are doing with it- like assembler and machine code. C wasn't meant to compete with COBOL.
--
--

Checked by AVG anti-virus system (http://www.grisoft.com ).
Version: 6.0.561 / Virus Database: 353 - Release Date: 13/01/2004
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

definable levels of checking.

you are using version 1.0 of the compiler) - it is the way it is used and how well it is tested that counts. If you insist on using pointers that don't point to anything, what do you expect. On a decent machine with memory protection and privileges (like a VAX/Alpha) you should only be able to crash your own process, never someone else's. C is after all a high level assembler (anyone used Plan ??), and while there may be better languages for writing operating systems [1], the closer you get to the hardware the more useful it is. For bit-twiddling it is perfect. I wrote the software for an analogue-addessable fire alarm over 10 years ago. Main board had a trusty Z80 with 32K rAM and 64K bank switched EPROM (Z80 =cheap to buy in quantity and available in CMOS, which is what you need for extended power fail sits.). Loop controllers - 8051 with 128 *bytes* of RAM but as much EPROM as you need, written in assembler and debugged with a 'scope. Had to do it for a fixed price and the hardware didn't exist at the time, and hardware guy had been rescued from redundancy at the age of 60 and had never done a digital board in his life. Interesting time - I had no idea how much information could be obtained just using humble 2 channel 'scope, and not even storage one. Oh, and I used C because Hitech (Oz company) did a cheap compiler for the Z80 and provided you avoided bit manipulation on stack items it generated tolerable code. Also meant I could use an intelligent EPROM emulator to debug and single step in machine code.
[1] (DEC->Compaq-> Now Hewlett Packard ACMS still has modules written in Bliss32. In fact I think it still their favourite language. Personally I still think VAX FORTRAN 77 version 3 running VMS V3 was the best combination, even for 'commercial' work since it had reasonable character string handling - and if you used a separate database handler you didn't need to use the languages rudimentary file handling. PS the London Teching hosp. where I used the latter used to use an Elliot 803 in the sixties - apparently it used mag tapes with sprocket holes (so I was told).

--
Andrew

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On Sun, 18 Jan 2004 22:40:28 +0000, Andrew

Notice I used quotes in my original description :)

But that's the point (pun not intended). C allows you to do such a thing, and the program will compile. Perhaps modern day C compilers are more robust than what I was used to (I last used C in earnest about 5 years ago), but my experience was that the C compiler did not automatically produce code that did runtime checking. Whereas pascal (etc) from the same vintage did.
BTW, of all the languages of which I am familiar I think C is/was my favourite - it was lean and mean. I never liked pascal that much, never did figure how anyone could like having to write "begin" and "end" in program constructs (much easier to use curly brackets - less typing). Fortran is model 'T' Ford vintage. VB is bloatware. And C++ was overloaded (pun intended) with features - very useful most of them, but my eyes glazed over a bit with some of the buzzwords like polymorphism, overloading, etc. Nothing wrong with C++, just that it wasn't for me really.
PoP
Sending email to my published email address isn't guaranteed to reach me.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
IMM wrote:

C was writen by engineers, as a way if writing assembler faster.
Thats why its good for operating systems.
Hwver you do need a *little* assembler here and there.
I have written an operating system in C and assembler.

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Kernigan and Rickie to be precise. They wrote the UNIX operating system with it (UNIX was a pun on Multix a Honeywell OS). The centre kernel of most UNIX versions is in machine code.

Depends on the compiler. A compiler only converts ASCII text to whatever. A written program is only a document, just like a letter.

Do you mean UNIX kernel? Add your bits and re-compile.
For applications C is not the thing as it can be slow to produce programs. A boss would be better with a 4 GL as it is faster and a slight learning curve.
C is very powerful.
--
--

Checked by AVG anti-virus system (http://www.grisoft.com ).
Version: 6.0.561 / Virus Database: 353 - Release Date: 13/01/2004
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
"IMM" wrote in message

That must be some new meaning of the word "precise" with which I was not previously familiar...
Kernighan and Ritchie must be two of the most famous names in computing. You spell them both wrong and call it precise. Get back under your stone and stop digging yourself into a deep hole again.
--
Andy



Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

So you are good at spelling? What do you know about C and UNIX, oh smarty? Probably just superficial stuff and then you an expert. Duh!
--
--

Checked by AVG anti-virus system (http://www.grisoft.com ).
Version: 6.0.561 / Virus Database: 353 - Release Date: 13/01/2004
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Just a small point. If you don't spell correctly, you will run into trouble with C especially. If you don't punctuate correctly then the results can be insidiously wrong and the compiler may not report it.

.andy
To email, substitute .nospam with .gl
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Since when has Kernighan and Ritchie been reserved words in C. Duh!!
--
--

Checked by AVG anti-virus system (http://www.grisoft.com ).
Version: 6.0.561 / Virus Database: 353 - Release Date: 13/01/2004
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
.

.andy
To email, substitute .nospam with .gl
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
IMM wrote:

Yes and no. C was devloped from B, which was developed from BCPL.
kernighan and Ritchie simply wrote tghe official book, there wer others involved in its design and evolution.

Yes and no. You can. of course write 'inline assembler' in 'C' in most complers.
However it is not 'C'
C nbeing a stack based language, and having very little cobncetp of registers - since the PDP CPU doesn't have many - does not map well or make efficient use of registers.
Neither has it any concept of using IO space within the language, nor is it very effeicient in all cases at doing bitmap operations.
To talk to the hardware usinc C alone is not possible. You have to have at some level at least an assembler coded subroutine to do e.g. an IO call, and other generic bit twiddling is usuially faster and easier to implement in assembler, as are interrupt service routines.
It is of couse he fact tghat RISC chops are now being produced that enavle almost pure C to be used to drive them - the are ooptimised for teh way it does things. However Intel type architectires do NOT map well into C and its a tribute to teh complier writers that we get teh performance we do.

No, I mean a dedicated operating system for an 8088 microprocessor board.
I have in fact written the equivalent of what a home computer running FORTH would have run in the early 80's. From scratch.

Horses for courese. Most higher level languages are woefully inefficient.
The problem with C is never speed, it is that it gets very big and hard to debug on higher level stuff. It is the actual problems of miantaining control over a huge project written in C that eventually make 4GL type lkanguase -0 inefficient tho they are speed wise - at least manageable in terms of software engineering.

Its as powerful as teh processor and machine it runs on.
Forth is smaller, but slower. In many respects its smaller than assembler in terms of the program sizs. Its a bitch to write tho :-)
Stuff like PDL or BASIC is easy to cobble up stuff in, but woefully slow. AND big.

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Andy Wade wrote:

Well it was 3ns a meter by the time I got into a proper electronics lab.
We even took a 100meter reel of cable, and shoved a pulse generator on it to check
The reflection did take about 600ns to come all teh way back..
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On Tue, 13 Jan 2004 00:55:27 -0000, "Andy Wade"

I am familiar with the basics of COFDM as well as the rival U.S. system and have read the papers by Stott and others.
While COFDM should give good multipath performance, the code rate and the guard intervals mean a compromise between the data rate and signal robustness. I understand that there are various issues around the UK system because of the limitations imposed by the current transmission arrangements, but I haven't looked at that in depth.
In practice I have seen cases where the bit error rate is noticably worse when cabling is poor or the antenna is not aligned correctly and there is visual evidence of multipath reception on analogue.
I suspect, therefore, that as Stott admits in at least one of his papers, while one can model some aspects of COFDM mathematically, some issues can only be determined experimentally. It would appear that the practicality may not be quite what the theory predicts.
DAB suffers in practice from limitations arising from the broadcasters trying to squeeze more into the spectrum than will give the best results. I haven't looked at the detail, but it would appear that DVB-T has some issues as well.
.andy
To email, substitute .nospam with .gl
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
"Andy Hall" wrote in message

OK, sorry, but that wasn't clear from what you said.

It should and does give good multipath performance, up to (a little over) the guard interval. As we're not using SFNs for TV the guard interval fraction has been set to the lowest DVB option (1/32) to minimise the loss of capacity.

ISTM that you're thinking more here of the choice of modulation constellation and code rate. In 1998 DTT launched with 64-QAM modulation & 2/3 code rate, giving about 24Mb/s net data rate. Following the demise of ITV Digital the BBC and Crown Castle decided to opt for 16-QAM to increase robustness, but to reduce the code rate to 3/4 to claw back some of the lost capacity. This combination gives about a 4 dB advantage in a gaussian channel. So we now have a hybrid situation with the BBC & CCI running 16-QAM 3/4 (~18Mb/s) but with the D3&4 mux (ITV, C4, etc.) and SDN (C5, S4C, etc.) still running 64-QAM 3/4.

The higher BER there might just be due to the signal being weaker, of course, or to long-delayed echoes.

I think most aspects of it are now pretty well understood and measurements agree well with theory. The performance of different receivers in the presence of long-delayed echoes does vary though, and depends (IIRC) somewhat on the Viterbi implementation. Unless you can be more specific about which of Jonathan Stott's papers you're referring to I can't really add any more.

That's a completely separate issue, not COFDM related. There isn't, AFAIK, the same flexibility as there is in DVB-T to change the transmission parameters to trade off capacity and signal robustness.
--
Andy



Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Well is this how you look at the rest of your DIY projects?...

more to ensure it works properly?...
--
Tony Sayer


Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

FWIW you could stack your loft full of aerials as long as their correctly connected and spaced etc. But the cable I would deffo recommend you upgrade. The new CT100 is far better than the older types of so called Low Loss aerial cable.....
--
Tony Sayer


Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

through so that it pokes out the bit that plugs into the telly, video etc. In the loft I split the aerial down lead into two and use a bit of 15 mm copper pipe hammered oval as a shield. Works fine. A bit of aluminium corrosion between the junction of copper and coax plug is bad news for reception.
--
Andrew

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

I wouldn't bet on it at those frequencies.
--
*Can atheists get insurance for acts of God? *

Dave Plowman snipped-for-privacy@argonet.co.uk London SW 12
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Related Threads

HomeOwnersHub.com is a website for homeowners and building and maintenance pros. It is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.