My part in the making of WiFi

Between 1994 and 1996 I was working at CSIRO Radiophysics (which turned into Telecommunications and Industrial Physics). Terry Percival was my boss' boss, and Diet Ostry and I shared an office. This story happened just a little bit before Terry, Diet and the two Johns had starting applying the radio signal unsmearing algorithms that CSIRO ended up with patents for which formed part of the WiFi standard.

One day Dr Percival set me (fresh-faced, obnoxious, know-it-all graduate) the challenge of solving the hardest problem in radio communications at the time: how can A and B communicate reliably, if A can't detect C's signal, and C can interfere with B?

My thoughts on the matter was that everyone was mis-stating the problem. It's only going to be a serious problem if you want to broadcast at 2.4 GhZ. If you drop the frequency of the signal down to something so low that even an iron ore mountain is transparent to it, it would be a very strange environment where A & C couldn't communicate.

So therefore, the real problem was that we were trying to do high speed networking. On the contrary, what we should be researching is extremely low-speed networking. How could we have useful and reliable communication at only a few bits per second?

Latency, jitter, high-speed CPUs to perform processing -- all these hard problems go away when you are only dealing in bits per second.

There were three other very good reasons why I thought low-speed networking was the right thing to look at, too: Linux, mining and submarines.

At the time, Linux was just making inroads into our thinking. The business world was dominated by IBM mainframes and (even in 1996) Windows 3.11 crashing was a daily experience for most people's workday.

The prevailing opinion that the team in the signal processing wing of CSIRO Radiophysics developed was that source-available (free-to-modify) software was unstoppable, and in a short time would conquer everything else, particularly Microsoft. After all, if the source was available, the program could never truly become unavailable or die, like proprietary software would. Software distribution bloat was about to go away, because we would all be getting our software in source form and compiling it. The days of elegant software that did exactly what it was supposed to without cruft were just around the corner because of the massive growth in volunteer developers who would tidy up anything and everything.

Which led me to the conclusion that we wouldn't really need high speed networks. The future was going to be everyone having these extremely reliable, high performance desktops (32-bit Linux never crashed; and the difference in this and also in performance was night and day compared to 16-bit Windows 3.11). All the software we would ever want would already be on our local harddisks -- all of it free -- and that there simply wouldn't be enough "stuff" to send over a network to even justify upgrading existing 9.6k modems. (I used to dial in on a 2.4k modem most of the time, myself).

I had been working on a related geophysics project as well. It was deployed on Linux (tying into the future-of-operating-systems theme) and deployed radio transmitters and receivers down boreholes in order to draw conclusions about the kinds of rocks in a region. It seemed like geophysical technologies were going to be a significant part of Australia's research future (at least I got something right!), and the need to deliver communications down into mines (where very low bandwidth would be inevitable) seemed like a worthwhile research direction.

The issues with the Collins class submarines at the time (including: how do we communicate with a submarine deep underwater?) made it seem to me like all the arrows were pointing at low-speed rather than high-speed communication.

I was so convinced that Terry and Diet (and John Deane, who was just down the corridor; and John O'Sullivan whom I think I interacted with a couple of times) were on the wrong track that I ended up quitting CSIRO and joining a private consultancy. This probably diverted me away from academia altogether which is where I otherwise would have gone. With the funding cuts that have hammered Australian research in the last few years, I'm kind of glad about this.

And it was fortunate for everyone else that I quit; I suspect I would have been a pain to work with if I'd stayed, and I'm sure I would have tried (probably unsuccessfully) to push the research in all the wrong directions. I suspect that I might have done such a bad job on the team that they might well have never made any progress to what we now call 802.11b Wi-Fi. On this basis, can I claim that I played a role in the creation of WiFi? By leaving and letting the team hire someone who actually had a clue what they were doing?

I'd like to say that I learn from my mistakes.

Before I got the private consultancy job, I applied for a quant-like role at County Natwest which in the end I turned down (again another lucky save given their history later). I was asked how I thought that County Natwest could make use of the Internet. My answer was that since no-one in their right mind would transfer money over the internet, that all it could be was an information portal.

A decade later (in 2007) I left Google because I was fairly convinced that it was going to fall apart in a few years as Wikipedia became ever more trustworthy that it would become everyone's first point of call for search. It's 2015 now as I search using Google over my home WiFi connection from a proprietary operating system: I have to admit that Bill Gates, Eric Schmidt and Terry Percival were right, and I was wrong.

Based on this, feel free to ignore anything in this blog that you disagree with, since it's almost definitely wrong. But I still think I'm right when I say that my my book of nerd-geek poetry has the best poems about nuclear physics you'll ever see. (And some fun stuff with robots, AI, first contact, and all sorts of other topics. There's even a vampire-at-the-blood-bank.) You really should go and buy it for yourself or your nearest and dearest nerd-geek friends. Here's the Amazon link: When Medusa went on Chatroulette.

@xdotai - Amy the virtual assistant

I suspect that X.AI have the shortest website domain name in the world: http://x.ai/

They make very clever software for organising meetings. Simply CC in their robot (Amy or Andrew, depending on your preference) and their robot will extract out vague time specifications from your emails and then start an email exchange with everyone else the email was sent to. Eventually you get a meeting entry created in your calendar.

Customers with Google Apps should make this a mandatory sign-up for all their senior staff as it saves hours per month on tedious to-and-fro work that can be automated.

Greg Baker is an independent consultant who happens to do a lot of work on HP DataProtector. He is the author of the only published books on HP Data Protector (http://www.ifost.org.au/press/#dp). He works with HP and HP partner companies to solve the hardest big-data problems (especially around backup). See more at IFOST's DataProtector pages at http://www.ifost.org.au/dataprotector

What a server-less retailer looks like

I've been helping a retail company with a few stores around Sydney. They don't have dedicated IT staff, so every support call is expensive, and having their own servers is very hard.

I got involved because they needed an internal ordering system, which I implemented as a collection of Google Spreadsheets. This was only a temporary fix, as I'm not a great fan of long-term data or business processes sitting in spreadsheets. But one thing led to another and they brought their email over to Google Apps.

To access the spreadsheets and their mail there is a Chromebook in each store. These have been very, very reliable. Months go past without any need for any IT support to fix anything.

They switched over to Saasu for their accounting mainly because they had multiple locations and needed staff to have access to invoicing at the same time. Xero would have been a possibility, but Saasu was (and still is) probably the easier product to use.

Recently they deployed Kounta as a point-of-sale system using ipads together with some Epson POS printers. This was mostly because Kounta supported Saasu; the alternative would have been Vend. In retrospect, Kounta isn't really designed for retailers: their home turf is restaurants and cafes. 

Having the sales report directly into Saasu automatically means that a whole chunk of head-office book-keeping has been eliminated. It's hard to imagine how this could have been done as efficiently if they were still using a on-premises copy of MYOB.

Reporting on what has been sold when has been helpful. For example, they've discovered that some of their frivolous accessory items are actually their best sellers, and they have been able to tweak their pricing as a result.

Internet access is crucial; most of the stores have an ADSL service which can fall back to a 4G service if the ADSL is not working. The original plan was to use Fritz! Boxes to do this, but the 4G modems that were available didn't actually work. It probably would have worked on something more up-market (e.g. a Huawei or Cisco) and might have provided some better diagnostic tools and would let the network be supported by a third party, but they couldn't justify the extra cost.

The procedure now is "in the event of an ADSL failure, turn off the router, and take the 4G modem out of the cupboard". Each store only has three important devices: the chromebook (mentioned before), the ipad (which is the point-of-sale system) and the receipt printer. The receipt printer is not wireless, so during ADSL outages they can't print receipts. Very few of their customers need receipts, so this isn't a big deal. Everything else will pick up on the other router.

Finally, they use Shopify for their internet ordering, again mostly because of its integration with Saasu. They use a combination of Shopify's iphone app and email to notify their staff about the order. This is then manually recorded in their point-of-sale system. Shopify also have a point-of-sale system and this might have been the best option, but Shopify charge a percentage of sales on their low-end plans and this ruled it out. No problems about this for internet sales, but for walk-in retail this seemed a bit greedy.

While there are perhaps more recurring costs (Google Apps, Kounta, Shopify, Saasu and the double internet connection at each store) than a more traditional solution, their savings do appear to more than make up for it. The end result is not enterprise-grade equipment by any means. There has been more cost-cutting and compromises than I am happy with. But the up-front costs are extremely low: lower than it would have been even to put a single good-quality server in at each store, let alone having fail-over server pairs.

Backup being one of my main interests, they only have four data repositories of any importance:

• Accounting data in Saasu. Xero have an ecosystem of backup providers, Saasu doesn't seem to. However, if Saasu failed for any reason for the long-term, they would have a very reasonable excuse to the tax office for their lack of records. (There would in fact be thousands of businesses affected, so the tax office would have to make some declaration about how to handle it.)
• Email and files in Google Apps. Spanning have a backup product for this with a remarkable recovery guarantee.
• Shopify sales. They are duplicated into the point-of-sale system and into Saasu, so if Shopify disappeared there is no financial information lost. There would be customer contact information lost, so perhaps they should use the integration with Mailchimp or feed it into another CRM.
• Sales records from Kounta. This is a bit of an area of weakness; the only option is manual exports. Vend seems to have better options here.

There are a few Windows desktops in head-office, but as the retail arm is just one part of the larger group, it's fair enough to say that the retailer is essentially server-less. While the transition away from mainframes was momentous in its time ("no tier 1 company can operate without a mainframe") and filled with multi-million dollar replacement projects, the transition away from Windows servers and maintaining internal Active Directory systems seems to be more of a slow slide. It won't be a big occasion: one day we'll wake up to discover that we've turned off the last Windows server and that nobody noticed.

Keywords from emails on Google App Engine

Today I was working on a project which needed to have a summary of comments (especially emails) sent by the staff working on it.

The software runs on Google App Engine (because I wrote it), so it was surprisingly easy to add this courtesy of AlchemyAPI.

App Engine can receive emails, that's just a matter of adding to the app.yaml configuration.

inbound_services:

- mail

- url: /_ah/mail/.+

  script: emailmgmt.app

  login: admin

Skipping most of the actual program, it was essentially this.

class EmailHandler(InboundMailHandler):

  def receive(self,message):

   (content_type,body) = message.bodies().next()

   a = alchemyapi.AlchemyAPI()

   data = a.keywords('html',body.decode(),{'sentiment':1})

   for k in data['keywords']:

      # store keywords and sentiment analysis 

   

That extracts the body out of the email, calls out to the Alchemy API, and returns the keywords from the email including the sentiment of the words around it (whether the word is positive or negative).

A bit of JavaScript had it displaying the keywords in colour. I sent the following email:

From: gregb@ifost.org.auTo: fun@app.appenginemail.comSubject: Site report 

They had some lovely stone gargoyles and some horrible fountains.

And out came some coloured summary keywords: stone gargoyles, fountains.

Greg Baker (gregb@ifost.org.au) is an independent consultant. If you are an industry leader and you need someone to catch your vision and help you make it reality, Greg might well be the right person to call.