Here is something else to consider. If you have a home with a security system, it may be hard wired into the telephone line to send out the alert. Mine has a "seizer" that will take over the phone line even if it is in use so that the alarm can send out its alert. I am dubious if this would work well at all with a VOIP setup. It may require you keeping the phone line at a minimum with a minimal local calling plan (e.g. pay per local call).
Unless of course if you have an network capable alarm system - but would you trust your ISP to handle the alert message? Or go with an alarm system that has a cell-phone capability (which depends on coverage and availability in your area).
My question is regarding the Telly MC1000 Home Entertainment Server. Does the recording and playback support closed captioning embedded in the NTSC video data stream (line 21 data aka EIA-608)? What about pass through, is the same VBI data preserved as live TV is watched?
This is crucial for hearing impaired users.
Thank you.
Their response:
Hello William,
This is a good question. Currently it does not keep the line 21 data intact from recording to playback. Passthrough will keep it intact.
Why are these companies even bothering with 802.11a/b?
There is a much better technology just around the corner in the form of
UWB. There is a company by the name of "Xtreme Spectrum" that has
already designed a chipset specifically for conveying A/V signals using
UWB. As I understand it, these signals are not prone to
degradation by multipath interference. However, penetration of
UWB signals through walls will be limited due to FCC restrictions on
allowable power limits of UWB signals. Here is a link on the
Trinity chipset:
Also, to address the issue of using 802.11a/b, it's really easy to do
it yourself if you have a PC equipped with TV capture card (e.g. ATI TV
wonder or ATI all-in-wonder, etc) and using Windows Media Encoder (as
an example) to encode a TV channel and broadcast it to your laptop/s.
I do this and it works really well, I put the laptop in "full screen
mode" while watching a TV channel and get pretty respectable
performance on old hardware (266 Mhz P2 laptop, 850 Mhz P3
encoder). I use WM9 (even though Microsoft "recommends" a P4 with
1.5 Ghz) for medium data rate encoding of video. I realize it
uses Microsoft products, but this is just one solution to using
802.11a/b for wireless media.
So, I end up with an instant 15" inch TV in front of me. It feels
even bigger because the TV is so close (as opposed to a 27" TV far
away). This solution works for me whenever the wife and I have
two different ideas of what to watch on TV. Yeah, I know it's a
expensive way to go about it solely as a TV solution but the PC
hardware/infrastructure was already there, it's just another way to use
it.
As usual, the hearing impaired users get the shaft.
There is no support for subtitling or closed captioning. This is a
very scary trend as more movies are available using the internet. Even
though MS's Media player and Real's RealPlayer support captioning, I have
seen very little use of this feature. Now that these movies are available
for download, how are the hearing impaired users going to be able to enjoy
the movies? What about foreign language support? With DVD's,
you were able to turn on/off subtitling at will.
Sidebar: It took an act of government (as I understand it) and the
FCC mandated closed captioning on 13" and larger TV's. Eventually,
the FCC mandated that new programming (with exceptions) be closed captioned
on the airwaves, phasing in to 100% by 2007 (barring extensions). More
info is here.
Will the same happen for the internet content? I believe that subtitling/captioning
support should have been done from the beginning because it's cheaper to
add in features from the beginning than it is to go back later and add the
features that should have been included in the first place.
Alright, enough ranting. Blockbuster still gets my money because I
can still can access captioning and subtitles from their DVD's and VHS's.
God forbid should they try to copy Cinemanow's approach and do the
same thing, discard subtitling/captioning support....
I am a programmer and digital hardware designer with 10 years experience in both areas.
I find that VHDL, while obtuse, is a terrific modeling language. There is a steep learning curve associated with it. Once you get the hang of it, it can do many things for behavioral modeling and RTL design of FPGA's and ASIC's.
It has been said that once you pick up VHDL, Verilog is easy to pick up afterwards.
It really depends on what you are trying to do. Are you trying to realize a design into an FPGA? For example, VHDL code is written differently when modeling behavior. When you're using VHDL to implement a real design for an FPGA, the coding style is different and many techniques you've learned in CS do not apply here. Good coding practice still applies such as well definied variable/signal names, proper data typing, generous use of white space, and verbose comments. However, that is where the similarities between C coding and VHDL coding end.
The real issue here with VHDL design to an FPGA are the tools. How well the tool that you've chosen (i.e. Synopsis Design Compiler or Synplicity's Synplify) reads in your VHDL, parse it, and create a gate level design using the low level building blocks available for a given FPGA/ASIC family.
Because of this, the code needs to be written in a specific way. To implement a counter, you would need to write a specific construct that the synthesizer recognizes.
But, that is just the beginning of your problems, there is no real good way to have a synthesizer infer that you want a ripple counter, compact counter, balanced, and so on. The only way to get exactly what you want is to define it gate by gate, what connections are connected to what. This provides for zero ambiguity how the design is to be implemented in an FPGA and you gain something such as performance or decreased utilization (there is a trade-off somewhere). In my experience, I find that synthesis tools try to find a happy middle.
The problem as I see it with the JHDL and other languages that try to supplant VHDL/Verilog is that they haven't matured. You will be hard pressed to find adequate tool support for those languages. Synopsis provides support for System C (if I recall correctly) but Synopsis products are horrendously expensive ($60K a year MAINTENANCE fee alone). Recently, EETimes reported that EDA companies are generally not happy with System C right now as its touted benefits don't seem to be happening.
Should you choose something other than VHDL/Verilog, your choice of platforms may be limited as well, such as using Solaris which are not cheap. It depends on your outfit, can they afford the cost and be on the bleeding edge or is it a shoestring outfit scraping to get by where it can (i.e. affordable FPGA tools on affordable platforms)?
There is the long term to consider. If you were to successfully develop a FPGA design utilizing JHDL for the first generation. What happens if support for JHDL disappears when the time comes to do a 2nd or 3rd generation of your design? The long term outlook for languages other than VHDL and Verilog are unclear.
There are engineers who are doing work in UWB for data transmission. There are a slew of UWB chipsets just waiting to be released once the FCC gives the go-ahead with UWB.
In a nutshell, UWB raises the noise floor of the EM spectrum and makes it more difficult to discern weaker signals.
Also, FCC's primary concern with UWB is with GPS which are used extensively for aircraft runways and naval use (docking equipment).
Slashdot Mirror
http://en.wikipedia.org/wiki/The_Culture#Drones
Unless of course if you have an network capable alarm system - but would you trust your ISP to handle the alert message? Or go with an alarm system that has a cell-phone capability (which depends on coverage and availability in your area).
My question to Interact-TV via their web site:
My question is regarding the Telly MC1000 Home Entertainment
Server. Does the recording and playback support closed captioning
embedded in the NTSC video data stream (line 21 data aka EIA-608)? What
about pass through, is the same VBI data preserved as live TV is watched?
This is crucial for hearing impaired users.
Thank you.
Their response:
Hello William,
This is a good question. Currently it does not keep the line 21 data
intact from recording to playback. Passthrough will keep it intact.
We will add this to our feature requests.
Regards,
Ken
--
Ken Fuhrman
Interact-TV Inc.
Why are these companies even bothering with 802.11a/b?
e f.pdf.
There is a much better technology just around the corner in the form of UWB. There is a company by the name of "Xtreme Spectrum" that has already designed a chipset specifically for conveying A/V signals using UWB. As I understand it, these signals are not prone to degradation by multipath interference. However, penetration of UWB signals through walls will be limited due to FCC restrictions on allowable power limits of UWB signals. Here is a link on the Trinity chipset:
http://www.xtremespectrum.com/PDF/xsi_trinity_bri
Also, to address the issue of using 802.11a/b, it's really easy to do it yourself if you have a PC equipped with TV capture card (e.g. ATI TV wonder or ATI all-in-wonder, etc) and using Windows Media Encoder (as an example) to encode a TV channel and broadcast it to your laptop/s.
I do this and it works really well, I put the laptop in "full screen mode" while watching a TV channel and get pretty respectable performance on old hardware (266 Mhz P2 laptop, 850 Mhz P3 encoder). I use WM9 (even though Microsoft "recommends" a P4 with 1.5 Ghz) for medium data rate encoding of video. I realize it uses Microsoft products, but this is just one solution to using 802.11a/b for wireless media.
So, I end up with an instant 15" inch TV in front of me. It feels even bigger because the TV is so close (as opposed to a 27" TV far away). This solution works for me whenever the wife and I have two different ideas of what to watch on TV. Yeah, I know it's a expensive way to go about it solely as a TV solution but the PC hardware/infrastructure was already there, it's just another way to use it.
Well, that's just my 2 cents...
As usual, the hearing impaired users get the shaft.
There is no support for subtitling or closed captioning. This is a very scary trend as more movies are available using the internet. Even though MS's Media player and Real's RealPlayer support captioning, I have seen very little use of this feature. Now that these movies are available for download, how are the hearing impaired users going to be able to enjoy the movies? What about foreign language support? With DVD's, you were able to turn on/off subtitling at will.
Sidebar: It took an act of government (as I understand it) and the FCC mandated closed captioning on 13" and larger TV's. Eventually, the FCC mandated that new programming (with exceptions) be closed captioned on the airwaves, phasing in to 100% by 2007 (barring extensions). More info is here.
Will the same happen for the internet content? I believe that subtitling/captioning support should have been done from the beginning because it's cheaper to add in features from the beginning than it is to go back later and add the features that should have been included in the first place.
Alright, enough ranting. Blockbuster still gets my money because I can still can access captioning and subtitles from their DVD's and VHS's. God forbid should they try to copy Cinemanow's approach and do the same thing, discard subtitling/captioning support....
Hello,
I am a programmer and digital hardware designer with 10 years experience in both areas.
I find that VHDL, while obtuse, is a terrific modeling language. There is a steep learning curve associated with it. Once you get the hang of it, it can do many things for behavioral modeling and RTL design of FPGA's and ASIC's.
It has been said that once you pick up VHDL, Verilog is easy to pick up afterwards.
It really depends on what you are trying to do. Are you trying to realize a design into an FPGA? For example, VHDL code is written differently when modeling behavior. When you're using VHDL to implement a real design for an FPGA, the coding style is different and many techniques you've learned in CS do not apply here. Good coding practice still applies such as well definied variable/signal names, proper data typing, generous use of white space, and verbose comments. However, that is where the similarities between C coding and VHDL coding end.
The real issue here with VHDL design to an FPGA are the tools. How well the tool that you've chosen (i.e. Synopsis Design Compiler or Synplicity's Synplify) reads in your VHDL, parse it, and create a gate level design using the low level building blocks available for a given FPGA/ASIC family.
Because of this, the code needs to be written in a specific way. To implement a counter, you would need to write a specific construct that the synthesizer recognizes.
But, that is just the beginning of your problems, there is no real good way to have a synthesizer infer that you want a ripple counter, compact counter, balanced, and so on. The only way to get exactly what you want is to define it gate by gate, what connections are connected to what. This provides for zero ambiguity how the design is to be implemented in an FPGA and you gain something such as performance or decreased utilization (there is a trade-off somewhere). In my experience, I find that synthesis tools try to find a happy middle.
The problem as I see it with the JHDL and other languages that try to supplant VHDL/Verilog is that they haven't matured. You will be hard pressed to find adequate tool support for those languages. Synopsis provides support for System C (if I recall correctly) but Synopsis products are horrendously expensive ($60K a year MAINTENANCE fee alone). Recently, EETimes reported that EDA companies are generally not happy with System C right now as its touted benefits don't seem to be happening.
Should you choose something other than VHDL/Verilog, your choice of platforms may be limited as well, such as using Solaris which are not cheap. It depends on your outfit, can they afford the cost and be on the bleeding edge or is it a shoestring outfit scraping to get by where it can (i.e. affordable FPGA tools on affordable platforms)?
There is the long term to consider. If you were to successfully develop a FPGA design utilizing JHDL for the first generation. What happens if support for JHDL disappears when the time comes to do a 2nd or 3rd generation of your design? The long term outlook for languages other than VHDL and Verilog are unclear.
Hope this adds some insight to your questions.
There are engineers who are doing work in UWB for data transmission. There are a slew of UWB chipsets just waiting to be released once the FCC gives the go-ahead with UWB. In a nutshell, UWB raises the noise floor of the EM spectrum and makes it more difficult to discern weaker signals. Also, FCC's primary concern with UWB is with GPS which are used extensively for aircraft runways and naval use (docking equipment).