Deployment vs. Development Costs

Well what came to mind was deployment as marketing. (you've got to sell your new gizmo)

We sell mostly to Physics types. We've got a long list of users and several trade shows that we go to as 'regulars'. If we were to make something for (say) geologists, then we'd have to do all the marketing leg work.. get names, find trade shows, do advertising..etc.

I don't know if this is what you had in mind.

George

On-orbit servicing of satellites. The payloads have to be man-rated, but you can replace propellant, gyros, and so on.

Another example is GPS. It works better than Loran did, and the receivers are cheaper, but the infrastructure is $$$$.

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs 
Principal Consultant 
ElectroOptical Innovations LLC 
Optics, Electro-optics, Photonics, Analog Electronics 

160 North State Road #203 
Briarcliff Manor NY 10510 

hobbs at electrooptical dot net 
http://electrooptical.net

A good example may be in the works today - self driving cars.

Now, to develop a self driving car is pretty big bucks, but it is just an engineering exercise. Several companies have them today.

But, to deploy them is a whole different matter. Besides the costs of building the cars, you also have legal and liability costs, the cost to 'persuade' lawmakers to pass laws that make it possible to deploy, the infrastructure of new signs and procedures (How do you notify all the self driving cars that this overpass is closed for repairs/maintanance?) and a thousand other considerations.

On the same note is justs electric vehicles. Developing one is a no-brainer. Deploying them has proven to be anything but!

Charlie

A worse disaster than the PPACA. ...Jim Thompson

--
| James E.Thompson                                 |    mens     | 
| Analog Innovations                               |     et      | 
| Analog/Mixed-Signal ASIC's and Discrete Systems  |    manus    | 
| San Tan Valley, AZ 85142   Skype: Contacts Only  |             | 
| Voice:(480)460-2350  Fax: Available upon request |  Brass Rat  | 
| E-mail Icon at http://www.analog-innovations.com |    1962     | 
              
I love to cook with wine.     Sometimes I even put it in the food.

(snip)

I don't know if this will help, but it reminds me of MCI.

As well as I remember the story, they had microwave links to allow truckers to communicate. When they had enough such links, someone figured out that they could use it for a long distance phone system.

Designing and deploying a long distance phone system for millions, or 10s of millions of customers from the start likely isn't easy, but building on an existing system isn't so hard.

The problem is always knowing how fast to scale up. If you have a sudden large demand, you need to build up fast, but then you might overshoot the demand and waste a lot of money on unneeded infrastructure.

Getting a little farther off the subject, there was some years ago a major internet outage in So. Cal. For redundancy, there were links leased from, if I remember, both ATT and MCI, so there shouldn't have been a problem. But it turned out that for at least some part of the link one of them leased fiber from the other, and a backhoe went through the fibers on that link. That is, the one place where there wasn't redundancy.

But competition and redundancy might not be part of the discussion.

-- glen

"Tim Wescott"

** The lack of obvious examples indicates your notion is essentially false. ** How about the light bulb ?

.... Phil

Either that or I'm too dumb to know one -- but I think you're right.

We decided to just leave it out. That made it easy.

--
Tim Wescott 
Control system and signal processing consulting 
www.wescottdesign.com

One such technology that comes to mind is high-definition television. Specifically, Over-The-Air broadcast HDTV.

In the early years (circa 1990), I don't think a lot of attention was paid to the deployment costs. New digital transmitters, new broadcast antennas, transmission lines, and new digital recording/playback equipment was requi red for at least two reasons: #1) The analog plants simply couldn't transm it the new signals, and #2) The analog plants made all the revenue.

It was a chicken-and-egg thing for a while. Broadcasters outside the top 1

0 markets didn't want to build new plants for no new viewers or advertisers . Consumers didn't want to buy HDTV receivers if no broadcasters were tran smitting in HDTV (even if only a few shows or hours each day).

Then there are the actual nuts-and-bolts to consider: The TV towers themselves often could not structurally support a 2nd transmi ssion system, having been initially designed for only one such structural l oad. Then there's the whole problem with license and spectrum availability . The list goes on and on. (The FCC eventually had to force this on the l ittle guys..)

Keep in mind that at the time, there would be few viewers with HDTV-capable receivers. And so, advertisers understandably would not pay a 2nd fee for carriage on HDTV. TV station owners would have to cover the HUGE operatio nal costs while simultaneously making no additional revenues. (Note however that there were some pretty creative work-arounds, but by and large terres trial HDTV was a flop from the start.) Not so much on CATV/Satellite, but that's a different story.

CATV & satellite guys got a direct feed (network or station, via fiber, mic rowave or ??), but high-power Over-The-Air HDTV morphed rather quickly into multi-channel standard definition. It quickly became the only way to main tain profitability.

Anyway - that's my $0.02

Not a great example. LORAN died of terminal neglect, not technical deficiency. Electronically and computationally, LORAN receivers (were much simpler than GPS receivers, ranging from the frequency bands used, to the received power, to the calculations. That very few units were being built killed the economics. While GPS provides better accuracy than basic LORAN, the long planned (but never fulfilled) eLORAN upgrade would have put LORAN in the same ballpark as basic GPS (~10m resolution), at modest cost to upgrade the transmission chains, and moderate increase in complexity of the receivers (although still simpler than GPS receivers). But even unenhanced LORAN (~400m) would have been plenty to get you to a port or airport.

Given the significant (near) single point vulnerabilities of all of the satnav systems, many people thought LORAN made an almost perfect backup system - cheap (killing it saved a reported $190m over five years, which would have included the eLORAN upgrade - you couldn't get a single GPS bird into orbit for that), much more resistant to jamming (typically signals were something like *50db* stronger at the receiver*, and GPS jammers are everywhere today), and a totally different technology, with totally different points of failure, and essentially complete independence from GPS. And given the CPU requirements of GPS, adding LORAN to a GPS receiver would have been possible in many cases with just an add-on RF module.

Instead LORAN was just barely kept alive (and shutdowns were attempted several times), so of course no one built hardware to use it. And then finally one of the justifications to finally shut it down was that usage was minimal.

And it's far from clear that the current (US) GPS system is going to maintain a full complement of satellites over the next 15 years, given likely retirement rates (most of the active birds are operating well beyond their design lifetimes already), and the rate of replacement launches (the latter being impacted by numerous development delays and funding issues). At least GLONASS is back online, and we may see Galileo and Compass** online by 2020, so we'll have some redundancy there if the application needs it.

Sorry, this is a bit of a hobbyhorse for me...

*While that's hardly jam-proof, the resulting increase in power requirements would require massive (and thus easy to find) jammers, or very short effective ranges. Consider a typical (small) 100kw LORAN-C transmitter. The rule of thumb is that the jammer needs to get ~20db more noise to the receiver than the actual signal in order to effective jam the receiver - so a 100kw(!!) jammer would manage to jam only a 100 mile radius near the outskirts of a chain's normal reception area (~1000mi). That same 100 mile jamming circle would take on the order of *one* watt for GPS. The North Korean's are intermittently jamming GPS over half of South Korea with a few dozen watts. **The global version of Compass, that is - the regional system (aka Beidou) has been fully operational for a couple of years now, which is great if you live near China.

Agreed. With the sort of horsepower available for a dollar or two nowadays, you could track every GRI on the *globe* (if you could get signal from each) and still have CPU left to play a decent game of chess!

Depending on GDoP, LORAN could get accuracies on the order of 200m and precisions closer to 20m! Close enough for a fisherman to find a lobsterpot he dropped the day before...

In those regions where multiple GRI are accessible, I suspect it would be relatively easy to improve on this (as well as resolving tome of the "ambiguous" TD pairs that occur on a single GRI).

The antenna may be an issue...

I think GPS offers more global coverage. IIRC, there are dark spots where no GRI effectively covers the area.

And, you'd probably want to compensate for propagation delays over water vs. over land. But, hell, a LORAN receiver was a few *KB* of code (on an 8b CPU). You could store a detailed map of the globe in the other hundred KB available in a cheap SoC! :-/

Assuming you mean:

Approach A: Development cost $A1 Deployment cost $A2

vs.

Approach B: Development cost $B1 Deployment cost $B2

and your point being that you may have erroneous costs for A2 & B2 in each of the above (e.g., perhaps assuming them to be equal?).

The obvious example (IMO) would be "software updates" for desktop PC's. (or, any other product for that matter).

I.e., you estimate the cost of supporting an update to be very low (you release a new piece of code that knows how to install itself, stop any competing services, start new services, restart computer, etc.). It's "inexpensive" to distribute those updates (let users download them, etc.).

This drives A1 down and lets you con yourself into thinking A2 is also low.

In reality, A2 has lots of user-borne costs that, eventually, appear in the user's TCO -- effectively making your A1 *look* much higher (even though the user didn't give YOU the monies directly, he still bore the costs!)

The alternative approach is to remove the user from the update process. E.g., "auto updates". This increases your B1 and B2, slightly. But, offsets (hopefully) the "hidden" costs that were associated with A2 in the original implementation.

Of course, the real solution is C -- don't *need* so many updates! (how many buffer overrun errors do you need to stumble upon before you realize they *all* need to be rechecked???!)

You could also spin this other ways drawing on the ACTUAL "user experience" with auto updates, etc.

Sorry, I could probably come up with a better example but I've got "workstations on the brain", lately :<

That's part of what eLORAN units do.

My RF is not good enough to tell me how difficult a truly compact

100kHz antenna (compact = "fits inside a cell phone") would be, but in many applications a modest whip is all you need for 100kHz signals. And many LORAN antennas are just that. I believe a simple loop should be doable inside a cell phone sized case, but would leave any definitive pronouncement on that to the RF guys. Plus 50db of extra signal strength makes up for a lot of antenna deficiencies.

Don't try using GPS near the poles, inside buildings or in city "canyons" either. LORAN would suffer near the poles as well, given the distance to any transmitters, OTOH, 100KHz signals have decent penetration through structures. In general long range over-water/pole navigation would need something in addition to LORAN for the dead spots, but numerically those are pretty limited applications. VLF/Omega used to fit that role nicely (also a cheap system), although INS would probably be the system of choice today for most of those applications.

Although if you want coverage near the poles, a GLONASS receiver will help a lot. And we seem to be well on the way to universal combined GPS/GLONASS receivers.

[attrs elided]

Oh, OK. It's been ~35 years since I worked with LORAN, so... :>

But, the idea made sense "way back then". Unfortunately, when you're dealing with ~2MHz 8b processors and hundreds of bytes of RAM, there's only so much you can do, practically...

Agreed -- subject to the caveat in your first statement.

We used a "CB whip", approx. The idea of something comparable sticking out of a (modern) cell phone is amusing!

[almost as amusing as seeing a *dial* on a cell phone!! :> ]

Exactly. We looked into the idea of marketing them (LORAN receivers) for municipalities to track their vehicles (police, fire, service), livery companies to track their cabs, etc. Of course, that's all now done with GPS...

With the sorts of compute horsepower you can get cheaply, today, all of these would be lead pipe cinches!

E.g., our first plotter required the user to contact us (manufacturer) for "coefficients" based on the region in which he was expecting to be operating. We'd run an algorithm on the DEC mainframe that we shared with Accounting that would generate these "fudge factors" and the user (fisherman) would enter them into the plotter. *WAY* too hard for a 4b (i4004) CPU to "do the math" -- esp when most users operated in the same area day after day...

And, many of the "texpertise" that a LORAN user relied on could be eliminated with all the resources you could make available in a modern implementation. E.g., deciding when to bump up a cycle on the envelope to get up out of the noise (then having to remember how this extra 10us is reflected in your TD's)

Maybe you are having difficulty because you haven't defined your requirement very well. Any time you sit and look at an NRE vs RE balance you are looking at a development vs deployment tradeoff. I suspect you are looking for something more than that.

The last mile problem has a few good examples of develop vs deploy issues. We had really nice working passive optical network systems in the late 80s, but deployment costs were a huge hurdle. As the internet took off in the 90s, people developed ADSL and cable modems to work around the huge deployment costs of rewiring neighbourhoods with fibre. ADSL and cable modems were entirely a workaround for fibre deployment issues. Only now are we seriously biting the bullet, and rolling out mass fibre deployments. (Sent over my 1Gbps $25 a month internet connection :-) ).

Regards, Steve

(snip on GPS vs. LORAN)

Ferrite rods have been in use for many years for AM radios in the 1MHz range, and should also work in the 100kHz range. Electrically they are like loop antennas and not like whips, but much smaller.

Through structures as long as they don't have too much metal in them. They go through the usual home construction, but not the usual commercial building construction.

Note that AM radio signals don't go into tunnels (unless the tunnel is specifically designed to allow it) but FM signals do. The wavelength makes the difference.

(snip)

-- glen

Inevitably, there's an app for that:

(Just one of many).

Semi-modern LORAN receivers from 20 years ago (as you would find in aircraft) pretty much did all of that, and at worst had a tuning selectors to pick a chain, and then had a lat/long display for output. About as simple as you could make it.

OTOH, my first exposure to LORAN was with a set of hyperbolic curve overlay charts... Now *those* were baffling to most people...

Naw, I mean a *real* dial! (drawing a picture of one doesn't count).

I had an ancient (by now, probably almost 100 yrs!) "candlestick" MaBell telephone. Of course, damn near any phone that ever worked with the PSTN will *still* work with the PSTN (a bit of hand-waving, here). I designed a little dial-pulse to DTMF converter to cram into the base, behind the dial mechanism.

(see )

This was a great hack -- on several levels!

People using it for the first time would "marvel" at its age and the novelty of holding the mouthpiece (the candlestick) in one hand and the receiver in the other. (Shades of "Mr Drucker")

Then, after dialing the first digit (the dial mechanism is a bit stiffer than more contemporary offerings) and hearing the "beeps" from the DTMF generator, they'd be caught off guard.

Finally, anyone who thought about it was further amused as there is no (apparent) VALUE to generating DTMF from a dial -- it still takes the same amount of TIME to spin the dial AND the PSTN can decode dial pulses (the same is not true of generating dial-pulse from a "pushbutton" phone as the home may not have -- at the time the device was built -- touchtone service!)

Our receiver (mid 70's) just gave you TD's. IIRC, only supported tracking (displaying) two slaves at a time on a single GRI. A button for each let you bump up/down a cycle in the envelope (+- 10us).

Lat/lon (direct from TD's) didn't come (for us) until the second generation plotter and the next generation receiver. Plotter didn't include a receiver so it relied on TD's from an external receiver (though the plotter did the lat/lon conversion based on the TD's coming in).

All of this predated graphic displays (a plotter, today, would be a piece of software running behind a graphic display; ours drew your course on a piece of paper -- even commercial map sections though you had to obviously initialize the pen's position to the "right" spot on the map!)

Fishermen take them for granted. Second plotter could draw "curves of constant time difference" on a (blank) sheet of paper so you could make your own map, sort of. (this, of course, is trivial: hold one TD constant, advance the other, plot the point, lather, rinse and repeat. Trick comes when plotting a point takes a sizeable fraction of a second so you want to plot very few of them!)

Security Systems? Wireless vs hardwired.

Once, I was told to not bother developing some whiz-bang gizmo for security customers, because the selling price was $600, which we received; but cost of 'pulling wire' was $10,000, which we did NOT receive; so what customer would want it? Wow, that was a major eye-opener for me.

"Petticoat" .... "Junction!"

Be careful Don, some folks know what you're talking about...

--
Randy Yates 
Digital Signal Labs 
http://www.digitalsignallabs.com