If it's strong enough you can see SSB. Given the bandwidth, the power is spread pretty thin (it's hard for me to imagine I said that - SSB is wide? Being narrowband was a selling point over AM and FM. How far we've come!).
For the record, I'm also a digital kind of guy, and have made a fair number of JT9-1 contacts recently as well as being an FSK441 lurker.
I think we're in fierce agreement. One of these days I hope to work you on the air. 73, Bruce!
You said, "CSMA doesn't work that well on HF. Sometimes you should be able to share a frequency with distant operators even though they fade in and out, etc. However, it makes sense if you are doing automatic link establishment."
The reason I mentioned a listen-before-transmit was to try and mitigate the unintentional-yet-preventable interference that would undoubtedly occur if SSB and data modes where thrown together cheek by jowl. All it would take would be a DXpedition working split to cause havoc. In the case of an SSB DXPedition, I'd hope that the human ops would be listening on their tx freq to prevent them from transmitting over a data QSO. This does not always happen, I realize. Given that some?/many?/most? data operators have the audio turned down and are busy looking at their rx freq on waterfall instead of actually listening, they could unintentionally QRM an SSB signal as they go "UP UP UP" with the VFO to be heard.
I agree your proposal is ambitious, but I think it's probably the right thing to do given the surge in popularity and utility of the newer data modes.
...it could be fertile ground for experimentation...
It is a fertile ground for experimentation! You need look no farther than the recent influx of extremely spectrum-efficient modes developed by K1JT. He's developed modes tailored for most any propagation mode/band including meteor scatter, moonbounce, etc.
The newest of the lot, the JT9 modes, are capable of decoding signals as far as 42dB into the noise!. The fastest JT9 mode takes 1 minute per transmission but can decode at a S/N of -27dB - that's noise with 500x the power of the signal.
I agree completely. The current 'gentleman's agreements' (aka voluntary band plans) do work and can continue to do so as long as they're also amended to reflect the new bandwidth-based FCC rules and are still recognized by the FCC in instances of interference. A quote from Riley Hollingsworth: "Band plans are voluntary in nature," Hollingsworth acknowledged in each of the similarly worded letters. He said the FCC depends upon voluntary compliance because it minimizes the necessity for the Commission to be called in to resolve amateur problems. "Where interference results from band plans not being followed," Hollingsworth continued, "the Commission expects substantial justification to be shown by the operators ignoring the band plans."
According to this Wikipedia entry, region 1 already has a bandwidth-driven bandplan and hints that the RSGB's plan (that the UK gov't accepts as official) will too.
The end goal of moving toward more spectrally-efficient digital modes for all forms of communication is laudable, but I think that there still needs to be some 'semi-official' protection for the traditional SSB phone modes while they're still in widespread use. Most robust digital modulation schemes are fairly immune to interference from adjacent SSB voice transmissions; unfortunately the converse is not true - my Mark I ears are not immune to nearby digital interference. As long as we still have band plans that encourage the separation of all digital modes from the analog modes, I fully support your proposal.
A question, though: How does spread-spectrum fit into your bandwidth-based plan? Do you consider the bandwidth to be what's used by each individual chip or the SS signal over all its carriers?
How do you feel about introducing a CDMA-esque automatic listen-before-transmit rule for computer-based digital modes, particularly with the growth of unattended stations?
PS - There's a typo in item 79 in the 20m, 6kHz section of the proposed bandwidth table - you have the lower limit as 1.150 MHz instead of 14.150 MHz.
Remember that this initiative was out of the UK originally and was aimed at turbocharging the CS curriculum at the University of Cambridge’s Computer Laboratory. I'm amazed they've done as well as they have in the US given they didn't get FCC certification until April 2012; literally minutes before they went on sale.
I ordered 5 from newark.com on November 17th. They were shipped on Nov 27th. Three were defective - I RMA'd them on Jan 7th and got the replacement ones (which were all ok - whew!) a 3-4 days later.
From their website: "7200 Expected to ship 6 Feb, 2013". When I ordered mine they were backordered until Dec 26th, but mine came early. I assume their estimate is worst-case.
Go ahead and order some - they won't charge your card until they ship, so you're not out anything. I know one thing for sure - you won't get any unless you bite the bullet and order some!
A band of ingenious fireflies, in a fit of magnanimity, decided to bestow upon us mere mortals the gift of their superior LED technology. Down they flew from their mountaintop aerie, each carrying a pair of Super-Ultra-Bright (tm) Firefly-made LEDs in their little firefly feet, and upon reaching Belgium, they lightly dropped them into the hands of grateful research scientists.
Simple, non-technical solution: Refuse to rely on a foreign source for materials deemed critical to the nation. Maintain your own production capability even when buying a cheaper foreign product (and stockpile if you must), but don't let your domestic production capability falter.
I think they've done remarkably well considering this was a shoestring operation from the start and they only expected to sell 10k units. I think they've dealt with a 100x increase in demand fairly well.
I've done the visual beacon ID thing a few times. My CW skills are fairly poor, so sometimes that's the best way for me to ID a beacon.:-( I'm usually running MacLoggerDX and CocoaModem for RTTY and other HF modes (including CW), and the waterfall comes in handy.
You know about the CW skimmers, right? They digitize a chunk of spectrum, decode all the CW CQ's and callsigns and report them up to the mother ship. Sometimes helpful, oft abused.
I thought of another use, too. I'd like to have it monitor 50.250-50.280 or so for FSK441 meteor scatter signals. The possibilities are endless!
I love and use that site and am subscribed to get alerts. The problem is that I get alerts for openings where I can't hear anything as well as no alert when there's an opening I can use. If I scan the SSB portions of those bands, I can tell when there's an opening at my QTH, and maybe even include an audio snippet in the email. I could also include what stations the cluster 'heard' in the freq that popped my local squelch. If I wanted to have my house look like a Navy ship, I could use a constantly-rotating antenna and include the azimuth of the signal. (or 'rotate' the antenna electronically; hummm......)
Curse duplicate articles - I always end up posting in the wrong one. In that post you'll see a couple of things I use them for. I also plan on making a sporadic-E monitor for 6m, 2m, and 70cm amateur bands. That way it can ping me when there's DX afoot.
Aren't those cunning linguists clever? The answer always seems to be right on the tip of their tongue. They don't diddle around. They seem to be able to lick any problem.
Unless you are coding for 16-bit and smaller devices, those differences are negligible for getting your code to work.
Incorrect. Endian-ness is always an issue when working with structs, unions, or bitfields. I recently worked on a chunk of code that dealt with bit fields in a structure. Naively one would define it like:
typedef struct {
unsigned short bitfield1 : 3;
unsigned short bitfield2 : 5; etc...
The behavior of bitfields with regard to endian-ness is UNDEFINED! You're probably too young to remember the mess that endianness caused with IP addresses stored in ints. Those tasty 4 octets fit perfectly into an int (everyone assumed) and they were always stored big-endian. NOT! When 386-based unix came along all of the networking structs and netmask routines had to be changed, and things like htons had to be created.
Part of the portability problem is that C is so close to the bare metal. The other part is that the C language spec is horribly weak when it comes to handling architectural differences. The only reason code works at all across platforms of differing endianness is due to kludges and workarounds.
Having said all that, I do like C a lot. Not as much as Java, though.
WHAT? With C you have to worry about memory alignment, endian issues, native register sizes, etc. From this link:
shortshort signed integer type. At least 2 chars in size. int basic signed integer type. At least 2 chars in size.
How many coders rely on an int being wider than a short? The language spec says that can both be as narrow as 2 bytes! These ambiguities, as well as the mess that different architectures make of structs and unions makes your assertion laughable.
The President can't order a Trillion dollar coin be struck so it's a waste of time.
Yes he can, by ordering/enticing the Treasury Secretary to do it. He's Obama's appointee, after all.
Emphasis mine: "31 U.S.C. 5112(k) as originally enacted by Public Law 104-208 in 1996:
The Secretary [of the Treasury] may mint and issue bullion and proof platinum coins in accordance with such specifications, designs, varieties, quantities, denominations, and inscriptions as the Secretary, in the Secretary’s discretion, may prescribe from time to time."
The Bureau of Engraving and Printing prints federal reserve notes and the Federal Reserve bank issues them. The US Mint mints coins. Platinum coins can be minted in any face value by the Treasury Secretary at any time and as he/she sees fit, but the BEP can only print and the federal reserve issue note quantities authorized by congress, and only in denominations already approved.
I've been in the situation you describe. I have a condo in the Cayman Islands, and in one instance the car I rented was imported from Japan where the speedometers are only in kph. The speed limit signs are in mph, so I had to do mental arithmetic to stay legal. I must not have been the only one to get a car like that - I saw some tourists going painfully slow in town where the speed limit is 25 mph. 25 kph is 15.5 mph. They must not have noticed the different scales.
To add to the problem, our USian instinct is to drive in the right lane if you're slower than the rest of the traffic (at least that's how it's supposed to work). In the Cayman Islands, they drive on the left, so the slow tourists were going 62% of the speed limit in the fast lane. A horn chorus ensued.
Slashdot Mirror
...and 640 acres of hemp ought to be enough for anyone.
If it's strong enough you can see SSB. Given the bandwidth, the power is spread pretty thin (it's hard for me to imagine I said that - SSB is wide? Being narrowband was a selling point over AM and FM. How far we've come!).
For the record, I'm also a digital kind of guy, and have made a fair number of JT9-1 contacts recently as well as being an FSK441 lurker.
I think we're in fierce agreement. One of these days I hope to work you on the air. 73, Bruce!
Thanks for the reply, Bruce.
You said, "CSMA doesn't work that well on HF. Sometimes you should be able to share a frequency with distant operators even though they fade in and out, etc. However, it makes sense if you are doing automatic link establishment."
The reason I mentioned a listen-before-transmit was to try and mitigate the unintentional-yet-preventable interference that would undoubtedly occur if SSB and data modes where thrown together cheek by jowl. All it would take would be a DXpedition working split to cause havoc. In the case of an SSB DXPedition, I'd hope that the human ops would be listening on their tx freq to prevent them from transmitting over a data QSO. This does not always happen, I realize. Given that some?/many?/most? data operators have the audio turned down and are busy looking at their rx freq on waterfall instead of actually listening, they could unintentionally QRM an SSB signal as they go "UP UP UP" with the VFO to be heard.
I agree your proposal is ambitious, but I think it's probably the right thing to do given the surge in popularity and utility of the newer data modes.
At that time the phrase "Well-regulated" meant something more akin to "smoothly functioning" than "politically restricted".
...it could be fertile ground for experimentation...
It is a fertile ground for experimentation! You need look no farther than the recent influx of extremely spectrum-efficient modes developed by K1JT. He's developed modes tailored for most any propagation mode/band including meteor scatter, moonbounce, etc.
The newest of the lot, the JT9 modes, are capable of decoding signals as far as 42dB into the noise!. The fastest JT9 mode takes 1 minute per transmission but can decode at a S/N of -27dB - that's noise with 500x the power of the signal.
Take a look at the WSPR page - on it you can access a database of WSPR transmissions, some of them at amazingly high km/Watt ratios.
vlm,
I agree completely. The current 'gentleman's agreements' (aka voluntary band plans) do work and can continue to do so as long as they're also amended to reflect the new bandwidth-based FCC rules and are still recognized by the FCC in instances of interference. A quote from Riley Hollingsworth: "Band plans are voluntary in nature," Hollingsworth acknowledged in each of the similarly worded letters. He said the FCC depends upon voluntary compliance because it minimizes the necessity for the Commission to be called in to resolve amateur problems. "Where interference results from band plans not being followed," Hollingsworth continued, "the Commission expects substantial justification to be shown by the operators ignoring the band plans."
According to this Wikipedia entry, region 1 already has a bandwidth-driven bandplan and hints that the RSGB's plan (that the UK gov't accepts as official) will too.
The IARU's suggested bandplan for region 2 already has suggested bandwidth limits and encourages member states to adopt it.
The end goal of moving toward more spectrally-efficient digital modes for all forms of communication is laudable, but I think that there still needs to be some 'semi-official' protection for the traditional SSB phone modes while they're still in widespread use. Most robust digital modulation schemes are fairly immune to interference from adjacent SSB voice transmissions; unfortunately the converse is not true - my Mark I ears are not immune to nearby digital interference. As long as we still have band plans that encourage the separation of all digital modes from the analog modes, I fully support your proposal.
A question, though: How does spread-spectrum fit into your bandwidth-based plan? Do you consider the bandwidth to be what's used by each individual chip or the SS signal over all its carriers?
How do you feel about introducing a CDMA-esque automatic listen-before-transmit rule for computer-based digital modes, particularly with the growth of unattended stations?
PS - There's a typo in item 79 in the 20m, 6kHz section of the proposed bandwidth table - you have the lower limit as 1.150 MHz instead of 14.150 MHz.
73 de K4DET
There is a real quantity called Toughness.
Everything's Up to Date in Kansas City. They've gone about as 'fur as they can go - Rodgers and Hammerstein got it right!
The GP has been reading too much Crichton. Crichton goes to great lengths to describe the plane/engine relationship in that book (page 116 or so).
Remember that this initiative was out of the UK originally and was aimed at turbocharging the CS curriculum at the University of Cambridge’s Computer Laboratory. I'm amazed they've done as well as they have in the US given they didn't get FCC certification until April 2012; literally minutes before they went on sale.
I ordered 5 from newark.com on November 17th. They were shipped on Nov 27th. Three were defective - I RMA'd them on Jan 7th and got the replacement ones (which were all ok - whew!) a 3-4 days later.
From their website: "7200 Expected to ship 6 Feb, 2013". When I ordered mine they were backordered until Dec 26th, but mine came early. I assume their estimate is worst-case.
Go ahead and order some - they won't charge your card until they ship, so you're not out anything. I know one thing for sure - you won't get any unless you bite the bullet and order some!
Fireflies Bring Us Brighter LEDs
A band of ingenious fireflies, in a fit of magnanimity, decided to bestow upon us mere mortals the gift of their superior LED technology. Down they flew from their mountaintop aerie, each carrying a pair of Super-Ultra-Bright (tm) Firefly-made LEDs in their little firefly feet, and upon reaching Belgium, they lightly dropped them into the hands of grateful research scientists.
Simple, non-technical solution: Refuse to rely on a foreign source for materials deemed critical to the nation. Maintain your own production capability even when buying a cheaper foreign product (and stockpile if you must), but don't let your domestic production capability falter.
I think they've done remarkably well considering this was a shoestring operation from the start and they only expected to sell 10k units. I think they've dealt with a 100x increase in demand fairly well.
I've done the visual beacon ID thing a few times. My CW skills are fairly poor, so sometimes that's the best way for me to ID a beacon. :-( I'm usually running MacLoggerDX and CocoaModem for RTTY and other HF modes (including CW), and the waterfall comes in handy.
You know about the CW skimmers, right? They digitize a chunk of spectrum, decode all the CW CQ's and callsigns and report them up to the mother ship. Sometimes helpful, oft abused.
I thought of another use, too. I'd like to have it monitor 50.250-50.280 or so for FSK441 meteor scatter signals. The possibilities are endless!
B. something that actually gathers the raw data.
I love and use that site and am subscribed to get alerts. The problem is that I get alerts for openings where I can't hear anything as well as no alert when there's an opening I can use. If I scan the SSB portions of those bands, I can tell when there's an opening at my QTH, and maybe even include an audio snippet in the email. I could also include what stations the cluster 'heard' in the freq that popped my local squelch. If I wanted to have my house look like a Navy ship, I could use a constantly-rotating antenna and include the azimuth of the signal. (or 'rotate' the antenna electronically; hummm......)
Curse duplicate articles - I always end up posting in the wrong one. In that post you'll see a couple of things I use them for. I also plan on making a sporadic-E monitor for 6m, 2m, and 70cm amateur bands. That way it can ping me when there's DX afoot.
Haven't they ever heard of Beware the Ides of March ? This will not end well, I fear.
Aren't those cunning linguists clever? The answer always seems to be right on the tip of their tongue. They don't diddle around. They seem to be able to lick any problem.
Unless you are coding for 16-bit and smaller devices, those differences are negligible for getting your code to work.
Incorrect. Endian-ness is always an issue when working with structs, unions, or bitfields. I recently worked on a chunk of code that dealt with bit fields in a structure. Naively one would define it like:
typedef struct {
unsigned short bitfield1 : 3;
unsigned short bitfield2 : 5;
etc...
The behavior of bitfields with regard to endian-ness is UNDEFINED! You're probably too young to remember the mess that endianness caused with IP addresses stored in ints. Those tasty 4 octets fit perfectly into an int (everyone assumed) and they were always stored big-endian. NOT! When 386-based unix came along all of the networking structs and netmask routines had to be changed, and things like htons had to be created.
Part of the portability problem is that C is so close to the bare metal. The other part is that the C language spec is horribly weak when it comes to handling architectural differences. The only reason code works at all across platforms of differing endianness is due to kludges and workarounds.
Having said all that, I do like C a lot. Not as much as Java, though.
I'm using the gargantuan 16LF1827 for my ZigBee(tm) mesh network node controller. I'm simply wallowing in the 384 bytes of RAM.
Certainly C is more cross-platform.
WHAT? With C you have to worry about memory alignment, endian issues, native register sizes, etc. From this link:
short short signed integer type. At least 2 chars in size.
int basic signed integer type. At least 2 chars in size.
How many coders rely on an int being wider than a short? The language spec says that can both be as narrow as 2 bytes! These ambiguities, as well as the mess that different architectures make of structs and unions makes your assertion laughable.
The President can't order a Trillion dollar coin be struck so it's a waste of time.
Yes he can, by ordering/enticing the Treasury Secretary to do it. He's Obama's appointee, after all.
Emphasis mine:
"31 U.S.C. 5112(k) as originally enacted by Public Law 104-208 in 1996:
The Secretary [of the Treasury] may mint and issue bullion and proof platinum coins in accordance with such specifications, designs, varieties, quantities, denominations, and inscriptions as the Secretary, in the Secretary’s discretion, may prescribe from time to time."
Overview of the trillion dollar coin.
The Bureau of Engraving and Printing prints federal reserve notes and the Federal Reserve bank issues them. The US Mint mints coins. Platinum coins can be minted in any face value by the Treasury Secretary at any time and as he/she sees fit, but the BEP can only print and the federal reserve issue note quantities authorized by congress, and only in denominations already approved.
You're welcome.
I've been in the situation you describe. I have a condo in the Cayman Islands, and in one instance the car I rented was imported from Japan where the speedometers are only in kph. The speed limit signs are in mph, so I had to do mental arithmetic to stay legal. I must not have been the only one to get a car like that - I saw some tourists going painfully slow in town where the speed limit is 25 mph. 25 kph is 15.5 mph. They must not have noticed the different scales.
To add to the problem, our USian instinct is to drive in the right lane if you're slower than the rest of the traffic (at least that's how it's supposed to work). In the Cayman Islands, they drive on the left, so the slow tourists were going 62% of the speed limit in the fast lane. A horn chorus ensued.