D-Star concept is fine, but using a patent encumbered codec definitely goes against the spirit of ham radio.
Home brew has always been one of the foundations of ham radio, and it should be possible (and legal) to homebrew a decoder for any modulation scheme (protocol) approved for ham radio use (at least in principle, even if it is difficult or rarely done in practice).
I don't take the iPad in the car, and I can read the 8.5x11 printout easier than my phone. My car doesn't have wi-fi, and I prefer to leave the iPad at home anyway. A in-car navigation system ght be better, but that is beside the point.
My wife uses the iPad for her e-mail. She receives an agenda for an upcoming volunteer meeting. She prints out the agenda to take with her. Again 8.5x11 is easier to read than her phone, and the iPad stays at home (not to mention that there is no open wifi at the meeting location).
I have an iPad at home, and while I'm a developer by trade, I do not develop iPad/iPhone apps.
I have two major gripes (and they are easy to guess):
1) Flash support. This is purely a practical objection (suspending my philosophical objections). This is a neat toy for having around the house. It is the #1 way my kids browse. There are a lot of child oriented sites that need flash ( my younger kids love pbskids.org ). If apple succeeds in driving flash from the web and everybody uses html5 then I'd be fine, but this will take forever.
2) Printing. I never missed it much on my iPhone, but when you are using the iPad it is hard not to think of it as a "computer", and a computer should be able to print. There are some apps that help here, but there needs to be universal support. I'm sitting on the couch reading an e-mail. Next to me hidden under an end table is my wifi laser printer. I really would like to print an email. I'd also like to print out map/directions to take on a trip. This really needs to be on the iOS list (even if it needs a daemon / iTunes on a computer to avoid having to load printer drivers in the iPad).
Short list:
1) Horowitz and Hill "Art of Electronics" 2nd ed -- human readable mix of theory and practical application -- must have
2) ARRL Handbook -- any year in the past decade -- great introduction to RF communications, good mix of theory and practice -- must have for ham radio
3) Wes Hayward "Experimental Methods in RF design" -- must have for homebrew ham radio enthusiast who wants practical advice but also wants to learn the theory
Why ham radio?
I'm back into Ham Radio after a 20 year lapse.
I got my license back when you had to travel to an FCC office for the test and pass a 5, 13, or 20 word per minute listening test for morse-code.
It is a great nerd hobby, especially if you get into the do-it-yourself aspect, digital modes, or especially software defined radio.
I can buy a SoftRock kit (google it) for less than $15 that does the initial downconversion and lets me use my soundcard+computer to visualize a large chunk of a single band, decode CW (morse), various digital modes and SSB voice.
WSPR mode allows you to put your computer to work sending and decoding ultra low power (milliwatts) + ultra low bandwidth (seconds per bit) to communicate around the world on battery power.
Ham Radio definitely took a hit from the internet and cellphones providing cheap and easy worldwide communications. Removing the morse code proficiency requirement and volunteer examimations has helped bring it back somewhat (I never minded the morse part, but it was a stumbling block for some who where in all other respects a perfect fit for the hobby).
If I was just interested in communicationI probably would not have come back to the hobby, but the nerd part is just too fun.
I'm currently using a cheap Direct Digital Synthesis chip (google DDS) interfaced with an Atmel microcontroller (google Arduino) as the basis of a do-it-yourself low power transceiver for digital modes.
Nerd heaven...
73 - Paul - K0EET
I don't necessarily disagree with you, but people said very similar things about the Mac when it first came out in 1984.
A favorite quote from Slashdot's favorite columnist:
San Francisco Examiner, John C. Dvorak, 19 Feb. 1984 regarding the new Macintosh from Apple
The nature of the personal computer is simply not fully understood by companies like Apple (or anyone else for that matter). Apple makes the arrogant assumption of thinking that it knows what you want and need. It, unfortunately, leaves the "why" out of the equation -- as in "why would I want this?" The Macintosh uses an experimental pointing device called a "mouse." There is no evidence that people want to use these things. I don't want one of these new fangled devices.
I knew I'd get that -- I hear it quite a bit, so I must just be in the minority.
I read Dune several times before seeing any of the movies.
It was like nothing else I'd ever read -- the "afterglow" of Dune carried me through Dune Messiah, Children of Dune, God Emperor of Dune, each one losing me a little more. I never finished Heretics of Dune, so maybe I'm just not a true fan.
I even tried one of Brian Herbert's books (shudder -- I'll have agree with you there).
I was told the mini-series was bad, and I tried to hate it, but for some reason I just couldn't.
I don't think any film could give you the whole experience, the mini-series adaptation was a bit mechanical, but at least they tried not to leave stuff out.
I never caught the Children of Dune mini-series, so I can't comment on it.
Hardin remained silent for a short while. Then he said, "When did Lameth write his book?"
"Oh--I should say about eight hundwed yeahs ago. Of cohse, he has based it lahgely on the pwevious wuhk of Gleen."
"Then why rely on him? Why not go to Arcturus and study the remains for yourself?"
Lord Dorwin raised his eyebrows and took a pinch of snuff hurriedly. "Why, whatevah foah, my deah fellow?"
"To get the information firsthand, of course."
"But wheah's the necessity? It seems an uncommonly woundabout and hopelessly wigmawolish method of getting anywheahs. Look heah, now, I've got the wuhks of all the old mastahs--the gweat ahchaeologists of the past. I wigh them against each othah--balance the disagweements--analyze the conflicting statements--decide which is pwobably cowwect--and come to a conclusion. That is the scientific method. At least"--patronizingly--"as I see it. How insuffewably cwude it would be to go to Ahctuwus, oah to Sol, foah instance, and blundah about, when the old mastahs have covahed the gwound so much moah effectually than we could possibly hope to do."
Maybe old hat to you network engineers, but I was previously unfamiliar with "bits per second.kilometer".
From the PC World article:
The measurement takes into account both speed and the ability to maintain it over distance, by multiplying the network's speed by its distance in kilometers. In this case, a network with an aggregate speed of 15.5T bits per second (Tbps) was able to maintain that speed over a distance of 7,000 kilometers (4,349 miles), or roughly the distance from Paris to Chicago
>>And if I were delivering a posix compatible system, I would do that conditionally so that posix apps (assuming there are any that actually rely on time()%60 == seconds_in_minute) would work.
Sounds sensible
>>This is what I said at first,
Yes
>> and what the linux man page implies.
Yes
I'm with you 100%, except that it's not what linux *does*.
OK -- I'm losing track -- maybe we're in agreement.
time() returns time_t which is stated as "seconds since the epoch"
However, tons and tons of legacy unix code takes the return value of time() and takes it mod 86400 to get the number of seconds since 00:00 of the current UTC day.
This legacy code works.
If time() were to include leap seconds, then the return value of time() would be N larger (where N is the number of leap seconds since the epoch) and time()%86400 would would give a value that was too large if interpreted as seconds since midnight of the current UTC day.
Regardless of the implementation of mktime (kernel or libc) the legacy code would break on linux.
The code does *not* break on linux, therfore time() on linux does *not* include leap seconds.
Linux time() matches POSIX and is *not* the true number of seconds elapsed since the epoch. Therefore linux must slew the clock to during leap seconds.
The definition of time() is (for better or worse) wed to legacy implementations of mktime / gmtime that don't understand leap seconds.
I read the same words in "man 2 time" but interpret them differently.
Despite saying in the heading that "time() returns the time since the Epoch" it really follows POSIX
See the source code for functions like gmtime() and mktime() and you will see that there is nothing to deal with leap seconds.
Consider the "C" snippet
time_t x; x = time(NULL); printf("hours since midnight: %ld\n", (long)(x % 86400)/3600); printf("minutes since hour: %ld\n", (long)((x % 86400)/60)%60); printf("seconds since minute: %ld\n", (long)(x % 86400)%60);
The fact that this gives seconds values compatible with the system (and not off by a second) shows this to be true.
time_t has been around since before UNIX people cared about things like leap seconds, and too much legacy code depends on simple integer math with time_t (like above snippet) to allow anything else. If an OS wants to "properly" deal with things like leap seconds it needs an internal representation other than time_t which has too much legacy baggage to be changable. Or it can use time_t and slew the clock for leap seconds which works fine for a rather large subset of systems.
Also, VHF for TV is really 2 bands: "low" channels 2-6 (55-89Mhz) and "high" channels 7-13 (175-217Mhz) with FM radio and other stuff in-between.
A VHF antenna for VHF "high" plus UHF, if you can get one, is nowhere near as bulky as a full VHF antenna
There are very few VHF low bad DTV stations
From solidsignal.com:
While the vast majority of high definition television is broadcast over the UHF band, 9% of the total digital TV stations in the United States utilize the VHF band for their broadcasts. A look at the numbers reveals the following:
* 76 markets have one or more digital station broadcasting in the VHF band
* 16 markets have 2 or more
* 4 markets have 3 or more
* 1 market has 5 VHF channels (Las Vegas)
This made sense, because VHF antennas are large, bulky, expensive, and difficult to install, and because _currently_ all digital television frequency assignments are in the UHF band.
Parent makes a good point but with a slight inaccuracy:
Some DTV have been VHF for years:
In Kansas City KMBC analog channel 9 has been DTV channel 7 for years -- I specifically bought a large bulky VHF-UHF combo antenna just for this reason.
Commonly used analogy in derivative trading: "Picking up nickels in front of a steamroller" (sometimes bulldozer).
Modest returns, low rate of failure, but really messy when you do fail...
A 20 bit address was a result of pin count (and cost of extra transistors).
16 bit registers and 20 bit address yields a 16 byte paragraph. 2^(20-16)
The cost 4 more address pins and associated circuitry could have been a show stopper.
However, I suppose they could have used a 256 byte paragraph and shifted the segment registers by 8 bits and just discarded the upper 4 bits to get yield a 20 bit address. This would just mean that the 8086 would have had many segment aliases. They could then add more address pins on the next version. Some lazy programs would have exploited the aliases and have broken code (similar to what happened when early MAC programmers used high address bits for their own uses and were hurt by the updgrade to 68020).
As it was the 80286 was 16 bit, but added a protected mode where the 16 bit segment register acted like an index into a table of segment descriptors. Fairly decent upgrade path for 8086 code (but MSDOS compatible), but only 16 bit MS OS/2 (which never caught on) a few versions of Windows ever exploited it.
Slashdot Mirror
That said, I don't think France dislikes D-Star for the same reason as me (and GP).
Agreed.
D-Star concept is fine, but using a patent encumbered codec definitely goes against the spirit of ham radio.
Home brew has always been one of the foundations of ham radio, and it should be possible (and legal) to homebrew a decoder for any modulation scheme (protocol) approved for ham radio use (at least in principle, even if it is difficult or rarely done in practice).
K0EET
I don't take the iPad in the car, and I can read the 8.5x11 printout easier than my phone. My car doesn't have wi-fi, and I prefer to leave the iPad at home anyway. A in-car navigation system ght be better, but that is beside the point.
My wife uses the iPad for her e-mail. She receives an agenda for an upcoming volunteer meeting. She prints out the agenda to take with her. Again 8.5x11 is easier to read than her phone, and the iPad stays at home (not to mention that there is no open wifi at the meeting location).
I have an iPad at home, and while I'm a developer by trade, I do not develop iPad/iPhone apps.
I have two major gripes (and they are easy to guess):
1) Flash support. This is purely a practical objection (suspending my philosophical objections). This is a neat toy for having around the house. It is the #1 way my kids browse. There are a lot of child oriented sites that need flash ( my younger kids love pbskids.org ). If apple succeeds in driving flash from the web and everybody uses html5 then I'd be fine, but this will take forever.
2) Printing. I never missed it much on my iPhone, but when you are using the iPad it is hard not to think of it as a "computer", and a computer should be able to print. There are some apps that help here, but there needs to be universal support. I'm sitting on the couch reading an e-mail. Next to me hidden under an end table is my wifi laser printer. I really would like to print an email. I'd also like to print out map/directions to take on a trip. This really needs to be on the iOS list (even if it needs a daemon / iTunes on a computer to avoid having to load printer drivers in the iPad).
Radiant: we're a little short on staff -- think you could raise the penalty for jaywalking?
Congressman: can do!
>>the results were 136 for, 70 against. The vote required 2/3 approval to
the question: is 136 / 206 >= 2 / 3 ??
is the same as: is 3*136 >= 2 * 206 (multiple each side by 206 * 3)
or: is 408 >= 412
or: DID NOT PASS
Short list:
1) Horowitz and Hill "Art of Electronics" 2nd ed -- human readable mix of theory and practical application -- must have
2) ARRL Handbook -- any year in the past decade -- great introduction to RF communications, good mix of theory and practice -- must have for ham radio
3) Wes Hayward "Experimental Methods in RF design" -- must have for homebrew ham radio enthusiast who wants practical advice but also wants to learn the theory
http://k0lee.com/images/dilbham.gif
Why ham radio?
I'm back into Ham Radio after a 20 year lapse.
I got my license back when you had to travel to an FCC office for the test and pass a 5, 13, or 20 word per minute listening test for morse-code.
It is a great nerd hobby, especially if you get into the do-it-yourself aspect, digital modes, or especially software defined radio.
I can buy a SoftRock kit (google it) for less than $15 that does the initial downconversion and lets me use my soundcard+computer to visualize a large chunk of a single band, decode CW (morse), various digital modes and SSB voice.
WSPR mode allows you to put your computer to work sending and decoding ultra low power (milliwatts) + ultra low bandwidth (seconds per bit) to communicate around the world on battery power.
Ham Radio definitely took a hit from the internet and cellphones providing cheap and easy worldwide communications. Removing the morse code proficiency requirement and volunteer examimations has helped bring it back somewhat (I never minded the morse part, but it was a stumbling block for some who where in all other respects a perfect fit for the hobby).
If I was just interested in communicationI probably would not have come back to the hobby, but the nerd part is just too fun.
I'm currently using a cheap Direct Digital Synthesis chip (google DDS) interfaced with an Atmel microcontroller (google Arduino) as the basis of a do-it-yourself low power transceiver for digital modes.
Nerd heaven...
73 - Paul - K0EET
I don't necessarily disagree with you, but people said very similar things about the Mac when it first came out in 1984.
A favorite quote from Slashdot's favorite columnist:
San Francisco Examiner, John C. Dvorak, 19 Feb. 1984 regarding the new Macintosh from Apple
The nature of the personal computer is simply not fully understood by companies like Apple (or anyone else for that matter). Apple makes the arrogant assumption of thinking that it knows what you want and need. It, unfortunately, leaves the "why" out of the equation -- as in "why would I want this?" The Macintosh uses an experimental pointing device called a "mouse." There is no evidence that people want to use these things. I don't want one of these new fangled devices.
I knew I'd get that -- I hear it quite a bit, so I must just be in the minority.
I read Dune several times before seeing any of the movies.
It was like nothing else I'd ever read -- the "afterglow" of Dune carried me through Dune Messiah, Children of Dune, God Emperor of Dune, each one losing me a little more. I never finished Heretics of Dune, so maybe I'm just not a true fan.
I even tried one of Brian Herbert's books (shudder -- I'll have agree with you there).
I was told the mini-series was bad, and I tried to hate it, but for some reason I just couldn't.
I don't think any film could give you the whole experience, the mini-series adaptation was a bit mechanical, but at least they tried not to leave stuff out.
I never caught the Children of Dune mini-series, so I can't comment on it.
I thought the SciFi network mini series a few years back was pretty faithful. I'd watch a new 3D big effects version, but it hardly seems necessary.
Asimov on this topic from Foundation:
Hardin remained silent for a short while. Then he said, "When did Lameth write his book?"
"Oh--I should say about eight hundwed yeahs ago. Of cohse, he has based it lahgely on the pwevious wuhk of Gleen."
"Then why rely on him? Why not go to Arcturus and study the remains for yourself?"
Lord Dorwin raised his eyebrows and took a pinch of snuff hurriedly. "Why, whatevah foah, my deah fellow?"
"To get the information firsthand, of course."
"But wheah's the necessity? It seems an uncommonly woundabout and hopelessly wigmawolish method of getting anywheahs. Look heah, now, I've got the wuhks of all the old mastahs--the gweat ahchaeologists of the past. I wigh them against each othah--balance the disagweements--analyze the conflicting statements--decide which is pwobably cowwect--and come to a conclusion. That is the scientific method. At least"--patronizingly--"as I see it. How insuffewably cwude it would be to go to Ahctuwus, oah to Sol, foah instance, and blundah about, when the old mastahs have covahed the gwound so much moah effectually than we could possibly hope to do."
From the PC World article:
The measurement takes into account both speed and the ability to maintain it over distance, by multiplying the network's speed by its distance in kilometers. In this case, a network with an aggregate speed of 15.5T bits per second (Tbps) was able to maintain that speed over a distance of 7,000 kilometers (4,349 miles), or roughly the distance from Paris to Chicago
>>And if I were delivering a posix compatible system, I would do that conditionally so that posix apps (assuming there are any that actually rely on time()%60 == seconds_in_minute) would work.
Sounds sensible
>>This is what I said at first,
Yes
>> and what the linux man page implies.
Yes
I'm with you 100%, except that it's not what linux *does*.
OK -- I'm losing track -- maybe we're in agreement.
time() returns time_t which is stated as "seconds since the epoch"
However, tons and tons of legacy unix code takes the return value of time() and takes it mod 86400 to get the number of seconds since 00:00 of the current UTC day.
This legacy code works.
If time() were to include leap seconds, then the return value of time() would be N larger (where N is the number of leap seconds since the epoch) and time()%86400 would would give a value that was too large if interpreted as seconds since midnight of the current UTC day.
Regardless of the implementation of mktime (kernel or libc) the legacy code would break on linux.
The code does *not* break on linux, therfore time() on linux does *not* include leap seconds.
Linux time() matches POSIX and is *not* the true number of seconds elapsed since the epoch. Therefore linux must slew the clock to during leap seconds.
The definition of time() is (for better or worse) wed to legacy implementations of mktime / gmtime that don't understand leap seconds.
In particular see /usr/src/linux/kernel/time.c:
unsigned long mktime()
I read the same words in "man 2 time" but interpret them differently.
Despite saying in the heading that "time() returns the time since the Epoch" it really follows POSIX
See the source code for functions like gmtime() and mktime() and you will see that there is nothing to deal with leap seconds.
Consider the "C" snippet
time_t x;
x = time(NULL);
printf("hours since midnight: %ld\n", (long)(x % 86400)/3600);
printf("minutes since hour: %ld\n", (long)((x % 86400)/60)%60);
printf("seconds since minute: %ld\n", (long)(x % 86400)%60);
The fact that this gives seconds values compatible with the system (and not off by a second) shows this to be true.
time_t has been around since before UNIX people cared about things like leap seconds, and too much legacy code depends on simple integer math with time_t (like above snippet) to allow anything else. If an OS wants to "properly" deal with things like leap seconds it needs an internal representation other than time_t which has too much legacy baggage to be changable. Or it can use time_t and slew the clock for leap seconds which works fine for a rather large subset of systems.
A VHF antenna for VHF "high" plus UHF, if you can get one, is nowhere near as bulky as a full VHF antenna
There are very few VHF low bad DTV stations
From solidsignal.com:
While the vast majority of high definition television is broadcast over the UHF band, 9% of the total digital TV stations in the United States utilize the VHF band for their broadcasts. A look at the numbers reveals the following: * 76 markets have one or more digital station broadcasting in the VHF band * 16 markets have 2 or more * 4 markets have 3 or more * 1 market has 5 VHF channels (Las Vegas)
This made sense, because VHF antennas are large, bulky, expensive, and difficult to install, and because _currently_ all digital television frequency assignments are in the UHF band.
Parent makes a good point but with a slight inaccuracy:
Some DTV have been VHF for years:
In Kansas City KMBC analog channel 9 has been DTV channel 7 for years -- I specifically bought a large bulky VHF-UHF combo antenna just for this reason.
Commonly used analogy in derivative trading: "Picking up nickels in front of a steamroller" (sometimes bulldozer).
Modest returns, low rate of failure, but really messy when you do fail...
Highly recommend book "When Genius Failed"
About the "rise and fall" of Long Term Capital Management -- based on the massive 1998 failure of a hedge fund based on mathematical risk models and included a Nobel prize winner among its directors.
ISBN-10: 0375758259
ISBN-13: 978-0375758256
Amazon link: http://www.amazon.com/When-Genius-Failed-Long-Term-Management/dp/0375758259/ref=sr_1_1?ie=UTF8&s=books&qid=1231168194&sr=1-1
Also see wikipedia writeup: http://en.wikipedia.org/wiki/LTCM
Stop utilizing that word!!!! AAaaaaaargghhhh!!
(but *NOT* MSDOS compatible)
EXACTLY!
Registers were going to be 16 bit, period.
A 20 bit address was a result of pin count (and cost of extra transistors).
16 bit registers and 20 bit address yields a 16 byte paragraph. 2^(20-16)
The cost 4 more address pins and associated circuitry could have been a show stopper.
However, I suppose they could have used a 256 byte paragraph and shifted the segment registers by 8 bits and just discarded the upper 4 bits to get yield a 20 bit address. This would just mean that the 8086 would have had many segment aliases. They could then add more address pins on the next version. Some lazy programs would have exploited the aliases and have broken code (similar to what happened when early MAC programmers used high address bits for their own uses and were hurt by the updgrade to 68020).
As it was the 80286 was 16 bit, but added a protected mode where the 16 bit segment register acted like an index into a table of segment descriptors. Fairly decent upgrade path for 8086 code (but MSDOS compatible), but only 16 bit MS OS/2 (which never caught on) a few versions of Windows ever exploited it.