Panasonic offering ultra-high capacity batteries in 2011?

From TFTS:


New Panasonic Lithium-Ion Battery to Power Up a House [New Li-Ion Battery Coming from Panasonic in 2011]

Panasonic is going to create one of the hottest batteries available to date. The new lithium-ion storage cell should power up a whole house in 2011 when it could be available to the general public. I don’t know about you but I’d want to plug that battery right into my laptop and see how much life it will be able to offer me.

Furnio Otsubo, president of Panasonic said that the new battery should offer sufficient electricity for about one week of use. That’s certainly something I could get used to although I bet the new battery concept is not going to be that affordable.

Read the rest at...

http://nexus404.com/Blog/2009/12/24/new-panasonic-lithium-ion-battery-to-power-up-a-house-new-li-ion-battery-coming-from-panasonic-in-2011/

PSK31 ... fun mode, boring conversation

So it seems almost everyone's PSK31 conversations are driven by the macros in the programs.  I can frequently tell what program people are using by the pre-fab comments they send.

I thought hams were into ragchewing? It seems like if I ask a question that isn't answered by a macro button, I just get

de 73 and thanks for this QSO on , good DX in 2009. de sk

and the conversation (such as it is) is over...

Emergency Power and the VX-170 HT

I picked up a 5AH battery and a charge controller from All Electronics to assemble an emergency backup power supply for my VX-170 HT, and when I tested it was surprised at what happened...

According to the manual for the HT, standby current was 20.5 ma (in saver mode), so I figured a drain of 20.5 maH on a 5AH battery should last about 11 days.  So after I charged up the battery and put the HT on it (just on saver mode), imagine my surprise when it drained the battery in a day.

Turns out that with the battery pack installed, and even with the battery pack fully charged, having the battery pack in the HT increased the current drain to nearly 200 ma, giving me my 25 hour life!

I've now pulled the battery pack and just run the HT off the SLA (Sealed Lead Acid) battery, and so far the voltage on the battery is holding up much, much better.

In an actual emergency, I expect the the drain to go faster, and have budgeted 20 minutes per hour of standby, 30 minutes of reception, and 10 minutes of transmission, 12 hours a day, for a life of about 6 days on the SLA (with then about 2 more days on the internal battery).  That gives me 8 days, which should be enough to get some sort of power back online...

Random Hacks of Kindness

If you go to http://www.rhok.org, you'll see an event that took place with software developers and groups involved with disaster relief.

Here's an article on the event: http://news.cnet.com/8301-27080_3-10398073-245.html

Other than some comments by readers of the article, there is no mention of amateur radio. Which is kind of interesting, because first place went to an application that relies on cellular phones to work. Well, I guess we'll see how that works out in the next disaster.

Wide AF SSB Radio for Digital

Doing digital over SSB HF is pretty nifty. Your computer essentially processes several channels of data at once, and allows you to monitor several QSOs. When you transmit, even though the radio is capable of transmitting a 2.5khz wide signal you only send a few hertz, allowing you to drop in your signal inbetween everyone else's.

In many ways, it's a software defined radio -- the real radio is just dropping a 2.5khz wide band of HF down to audio frequencies to make it easy for the computer to deal with.

But 2.5khz isn't really optimal for digital, it's optimal for voice. And as far as making do with existing technology, it's great.

But why not build a digital-oriented, low cost (!), SSB transceiver that passes through 10khz of bandwidth instead of 2.5? It would be useless for voice, for sure, but since sound cards can digitize at 44khz they'd have no problem with 10khz of spectrum all at once. Even 5khz of AF bandwidth would be twice as useful!

HF Email, Winmor, and AMPS, TDMA, CDMA, etc.

A small thread on the Winmor beta-test group on Yahoo groups arose around the subject of needing more Pactor (and eventually Winmor) stations because accessing email over HF is single threaded. Only one user can access a station at a time, and because the baud rate is so low for HF a station can be tied up for an extended period of time.

This kind of problem has been solved many times before. In the first generation of cellular phones (AMPS), an analog phone connection would tie up a channel (pair of frequencies) at the cell node for the duration of the call, much like the current HF approach does.

This first generation approach offers us some ideas for ham radio. The first is to use multiple channels to talk to multiple stations. In AMPS the channels were full duplex (using a pair of frequencies), but the same approach could be done with half-duplex.

This would probably require some custom, and very non-standard, radio equipment at the server end to handle multiple channels at once. It would be an interesting SDR project. Or one could just install multiple radios. In AMPS, there were two different bands for transmitting and receiving at the cell node, so duplexers are used to share antennas. This works well for a full duplex connection.

Even for a single radio, the Winmor channels work in 500hz bandwidths (and 1600 hz as well, but let's ignore that). You could easily put three of these in a standard SSB signal with spacing and have three "channels" for a single, normal radio. This gives a lot more capacity, albeit with more complexity. Issues around synchronizing the transmit and receive cycles on each channel arise, but that can be solved...

2G cellular moved to CDMA and TDMA digital, allowing sharing of channels. For HF email, this moves us into the realm of things like Aloha and Slotted Aloha, which are known, although not terrible efficient, means of coordinating multiple stations on a single frequency. But if the goal is to provide service to all and not allow a single user to "hog" a relay station, that would work.

Clearly, using an off-the-shelf radio is limiting (but not totally limiting), but custom hardware would really open this up to some sophisticated usage!

ARRL Radiogram from 1928

Here's a radiogram my grandmother received from my grandfather in 1928 ...

Click on image to see full size

Pretty neat!!

LDG AT200Pro antenna tuner, initial impressions

I just got the LDG AT200Pro and have some initial impressions...

• It's great.
• It's louder than I expected.  It uses relays (yay, I love relays :-) ), and cycles them on and off very quickly.  My wife thought it was broken, and I had to assure her that was normal behavior.  You would not want to try to sleep near it when it decided to retune.
• When I switch bands, reception is muted until I do a quick transmit to let it know the new band I'm on. Didn't expect that, although in hindsight it's obvious.
• None of there online documentation makes it sound like it comes with a power cable (which it does, unterminated).  I thought I was going to have to visit "The Shack" to get the right connector to build my own!
• Although I added its power connectors tapping off the main supply, this is going to push me to get the Power Pole distribution system working.
• It has a "rebate" of a 1:1 or 4:1 balun.  I don't have a need for one right now, so I have to guess what I'll need in the future.
• The bar graph display of power and SWR is a lot more usable than I expected.  Still, it seems to me for a similar cost they could have put in a few 7-segment LEDs instead (or the n-segment ones that display letters).
• The user-interface is modal and complicated once you get past basic tuning (basic tuning is trivial, but all the features are going to take a while to figure out).  Is there a rule in ham design that says everything has to be very modal?
• It seems to re-tune more often than I expected.  I guess I thought there'd be a tuning for a band, but any movement off a frequency to a nearby one seems to be a cause for re-tuning.  Again, not a complaint, just an observation...

So far, I love it.  What an improvement over my MFJ-871 that had some "factory defects" and was very touchy about tuning...

Positive ComputerWorld Article on Ham Radio

http://www.computerworld.com/s/article/9139771/Want_to_bone_up_on_wireless_tech_Try_ham_radio :

Want to bone up on wireless tech? Try ham radio

Abundant spectrum resources and an engaged research community are drawing wireless experimenters back into a hobby that many had forgotten.

Securing HSMM systems without violating FCC rules

There's a common thread to conversations about implementing HSMM (aka souped-up WIFI): If you cannot use encryption to secure links (because encryption is almost completely prohibited to amateur radio), how do you secure them from access by non-hams?

Let's start with a review of the FCC rule.  §97.113 (Prohibited transmissions) prohibits, in part:

messages encoded for the purpose of obscuring their meaning, except as otherwise provided herein;

 It seems to me that this prohibition rests on two things: (a) the purpose of the encoding and (b) the obscuring of the meaning.

Let's take an example of communications that everyone agrees do not violate this section: the CRC codes in AX.25 messages.

In a packet radio message, the contents of the message include a CRC (cyclic redundancy code) at the end of the message, which is used to verify that the message was received undamaged. Is the purpose to obscure the meaning of the message? Not at all.  The bulk of the message is in plain text, and the CRC merely allows any receiver (intended or otherwise) to verify that the contents of the message.  Does it in fact obscure the message? No, because the CRC can be computed via known algorithms.

Now, lets consider what would happen if we added public key encryption into the mix.  In public key encryption, there are two encryption keys used.  One is private and one is public. Let's say the public key is registered with the ARRL, who makes it available to everyone, amateur or not.  Thus, it is commonly known how to find the public key for any ham.

Messages encrypted with your private key can be decoded by everyone (who has looked up your public key), and if they decrypt successfully with your public key it can be safely assumed that you and only you encrypted them.  This allows you to "sign" messages.  Similarly, any message encrypted using your public key can only be decrypted using your private key.  Thus, anyone can encrypt messages for you and have them be readable only by you.

Let's apply this to the CRC.  What if the sender of the message (who is clearly identified in the packet) encrypts the CRC using their private key?

Anyone (intended receiver or not) can decrypt the CRC using the sender's public key (which they found on the ARRL website).  And if the decrypted CRC is correct for the packet, we know two things: we know that the message was received without errors, and we know that the sender specified in the header did, in fact, send the message (i.e., it was not spoofed).

OK, how does this work with the law?

Is the purpose to obscure the meaning of the message? Not at all.  Consider:

• The actual message -- the rest of the packet -- is not encoded.
• The CRC is just as readable as it was before; you decode it using the sender's public key, and then you match it to the message to validate the contents.  Even the meaning of the CRC is not obscured; it is readable by all who posses common knowledge.
• What is the purpose of the encoding? The base CRC encodes the data to ensure that there is no error in it.  The "enhanced" CRC is encoded to ensure that the sender is properly identified.

So, will you agree with me that you can use a public key encryption to "sign" messages to authenticate the sender?

(If not, stop now.)

If that's possible, then, of course, there is going to be something analogous with HSMM.  It will be possible to authenticate the sender even while the message is in cleartext, and the receiving system can decide if the sender is authorized to use the system.  If not, the message can be ignored. Again, if the ARRL (or some other recognized body) keeps the list of call signs and public keys, then "open" systems will merely need to look-up an unknown call sign to add its public key to a cache and then allow all hams in and keep all non-hams (who, we assume, do not have a valid call sign with an entry in the ARRL database) out.

Did I miss something? Tell me in the comments!

Emergency Communications and amateurs ...

I don't get it -- why do people on eham and qrz keep battling about whether emergency communcations is good or bad?  Well, apart from "because they can" ...

It seems to me that amateur radio operators have one real strong benefit to offer: If something breaks, amateurs can generally fix it.  If the antennas all get blown off the roof of the police department, who there knows how to repair them?  Who there could improvise one?  Who there could even guess what a quarter wave-length is for 480 mhz?

Exactly.  It's only the people who do this as a hobby and have been through the process of setting up a station who can solve these kind of problems.  And in a disaster, it's going to be those people who get communications equipment working again on short notice.

Do amateurs only have value in operating a communications network? Perhaps in being able to help others out getting their networks working again is a valuable skill?  Or maybe both...

More AT&T Woes, this time in San Francisco

I just returned from Oracle Open World (OOW) in San Francisco, and my iPhone was just struggling to work there.  I had to turn off 3G services to get a reliable connection, and even then there were times that it just wasn't working.

I hate to hammer on the point, but it really seems like the network's maximum capacity is dangerously close to its average usage; a small uptick in usage and things go downhill fast.  Clearly, AT&T should have a sense of the calendar of events in San Francisco -- OOW happens just about the same time every year and they must have noticed the spike in usage last year.

I'd hate to see what happens there if (when?) a major and destructive earthquake hits and everyone starts twittering "OMG I just saw a building collapse in SF"...

How to lure more young people into ham radio

Give them free 2m radios when they get their license!

Of course, that would be a bit expensive, although I suppose if the ARRL did this en masse it could find something inexpensive or get one of those cheap chinese HTs FCC certified...

Still, it's a thought! Your average 16 year-old who might be interested in amateur radio probably isn't going to have the $100 or so to get a decent HT, which is kind of a buzz-kill for the hobby.

Web Services & Packet Radio ... But! But! But!

When discussing web services and packet radio, I hear a lot of buts ...

• But XML is too inefficient to go over 1200 baud links!
  
  XML in its native state is very inefficient; but that inefficiency also gives rise to incredible compressibility; you can shrink XML in ratios of somewhere around 8:1 .
  
  
• But we've tried (HTTP, TCP/IP, etc.) over packet radio and it's just too slow to bear.
  
  All of these are probably in support of interactive user sessions, which web services is not (usually).  Web services are computer to computer communications, and usually do not have a direct impact on the UI.
  
  
• XML is very bandwidth inefficient
  
  I don't think there's a bandwidth shortage.  As far as I can tell, most packet nodes sit idle almost the entire time; that means lots of wasted bandwidth.
  
  
• HSMM (i.e., wifi with higher power levels or better antennas) is much better for this sort of thing.
  
  It's much better for running a traditional TCP/IP network, for sure.  But web services do not require  TCP/IP or HTTP -- those are just one of many ways to deliver web services.  And while HSMM delivers high speed, it is also a very small niche compared to 2m packet and doesn't have the ability to easily blanket a community with a signal.
  

 To be fair, when I raised the question, it was very narrow (has anyone tried this?) without a lot of explanation of why.  I'll try to answer why in another post soon.

Compressing XML for over the air usage

In the quest for packet based web services, one big problem -- at least a performance problem -- stands out: XML, which is used in SOAP messaging, is horribly verbose.

In his paper, Compressing XML with Multiplexed Hierarchical PPM Models, James Cheney examines the various means of compressing XML files. And while he pushes hard to get the very best possible compression by using XML-aware techniques, even the widely used gzip is able to achieve about an 8 to 1 compression, which is really good. Plus, gzip compression is used in HTTP, so it has a defacto use in transport compression. The best compression he found as more like 12 to 1 compression, but apparently a bit of a time hog.

Gzip also is built into Java, making it easy to build support there, and there are freely available gzip libraries for .Net and PHP, covering about 99% of all web site development.

??? Listening

I must be the only one who has a problem with "Callsign listening" as the protocol for announcing oneself on a repeater -- I usually miss the first part (during the "huh, someone's on the repeater" moment). I guess when you already know everyone by sound and call sign, it works great, but for newbie me, I spend time wondering "who was that?"

And if I have my radio scanning around a few repeaters, I'm guaranteed to only hear the last few letters of their call...

Why are there no web services over packet radio

Approaching the world of ham radio from the perspective of a long time computer software -- and enterprise integration -- point of view, it struck me today: why are there no web services support in amateur packet radio.

Web services are a fancy name for the ability to make a subroutine call across a network (or even on the same computer). They are based in eXtensible Markup Language (XML), which means that the call can pass in and return data of any arbitrary complexity. They are quickly becoming the standard for integration applications across a network, especially in situation where the applications don't normally know about each other.

There are some things about web services that make them a natural for amateur packet networks:

• They are fundamentally half-duplex, like our radio connections: You send in a call (which could be split across packets because of size), and then wait for a response.
• They could allow for a very nice, local front end to traditional applications like bulletin boards, which got killed by not only better connectivity of the internet but, I suspect, nicer web user interfaces.
• They allow for arbitrary experimentation with packet -- no having to come up with a separate KJ4NGS-xx for every application.

It's the last point that seems strongest to me -- the ability to quickly experiment with new services on the packet net.

There's a lot issues to be solved to make this work, but it seems to me to be something that is fundamentally at the heart of what amateur packet should do.

Random ideas for improving ham radio

Here's some ideas that occurred to me ... they may be new to me but not new to everyone else, so if these have been kicked around the lot a few times, forgive me...

1. Creating a standard for having a small data channel along with analog FM. Like DStar, only open standard and inexpensive to implement. Something like broadcast FM's Radio Data System, only not so bandwidth hogging. If nothing else, it could do some of the tricks DStar does (unsquelch only when someone is calling you, automatic call sign transmission, etc). There is no reason to toss FM-voice away just to get a digital sub-carrier.
2. With #1, repeaters could log usage (maybe this is a bad thing?), but with a public web site, then you could get a sense of when people are on.
   
3. Repeaters with Antenna Diversity to allow for better reception of weak stations. Would be especially good for ecomm work where field units might be 5W HTs while the repeater is 50W or more.
4. Using packet radio to advertise when you are available on a repeater. If I broadcast a "listening message" and someone shows up 5 minutes later, my listening message is lost.
5. "Packet pager" -- sort of like an HT crossed with a blackberry. Ability to send and receive text messages from a small handheld device using packet (APRS?).

All of these have a critical mass problem (except #3), so they're nice in theory, at least...

AT&T cellular maxed out?

I have an iPhone, and lately it's been dropping calls inexplicably. I say inexplicably, because it's worked pretty good up until now, and many times the phone is sitting perfectly still with many bars. It's just that their network is overloaded.

According to Sascha Segan's column in PC Magazine, AT&T is looking to ameliorate this problem by putting small cell nodes in people's houses and businesses and then using VOIP through their internet connection to get back to ma bell. Maybe VOIP will be as good as cell phone service, but in general it suffers from dropped audio whenever the cable bandwidth gets used by someone else in the household (or by me, trying to follow a web conference). It's not a great solution.

From a ham radio perspective, what I find interesting about this is that it's a warning sign: the cellular network has no resiliency, no ability to handle the slightest increase in demand as would be caused by a disaster.

When you consider that many people are "cutting the cord" and getting rid of traditional phone service, cell phones have moved from a luxury to a basic necessity. But it's clear, that need is not going to be met in a disaster, even a minor one; the cell phone system will gridlock.

And that's if all the cells remain functioning. If a disaster knocks out a small but significant percentage of cells, even normal cell phone usage will become very challenging.