Deployment vs. Development Costs

I'm trying to think of a good example of where there may be a distinct and valid tradeoff between the cost to develop some technology versus the cost to deploy it.

This is for a book chapter on systems design that I'm almost finished writing. The point of the example is to get people familiar with the concept of questioning their assumptions about how much things will cost when they start designing for markets that are markedly different for the ones that they are accustomed to working in.

In this case I'm classifying "development" costs as, basically, the NRE costs involved in making the technology work, and the "deployment" costs as the costs involved in putting the technology into the hands of the people who are going to actually use it.

Examples would be talking by radio vs. talking by phone, or traveling by car (with a road system) vs. traveling by air.

Unfortunately, the examples that I'm coming up with all have other obvious tradeoffs that overshadow the develop vs. deploy one, or they have not-so-obvious development costs (for instance it's far easier to develop a phone line to go across town than it is to design a radio transceiver, but if you want to develop a phone _system_ that includes long distance and millions of subscribers, then you've got a lot more development effort than you would for a radio transceiver, etc.).

Suggestions welcome. I'm at the point of just throwing up my hands and not trying to cite any specific cases, or to change the underlying target of the example somehow -- posibly to per-user cost vs. deployment, or something like that.

--
Tim Wescott 
Wescott Design Services 
 Click to see the full signature
Reply to
Tim Wescott
Loading thread data ...

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 
 Click to see the full signature
Reply to
Phil Hobbs

(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

Reply to
glen herrmannsfeldt

"Tim Wescott"

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

.... Phil

Reply to
Phil Allison

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 
 Click to see the full signature
Reply to
Tim Wescott

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.
Reply to
Robert Wessel

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! :-/

Reply to
Don Y

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 :<

Reply to
Don Y

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.

Reply to
Robert Wessel
[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)

Reply to
Don Y

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

Reply to
Steve Underwood

(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

Reply to
glen herrmannsfeldt

Inevitably, there's an app for that:

formatting link

(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...

Reply to
Robert Wessel

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!)

Reply to
Don Y

"Petticoat" .... "Junction!"

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

--
Randy Yates 
Digital Signal Labs 
 Click to see the full signature
Reply to
Randy Yates

Actually, I would have settled for "Green Acres" or just plain "Hooterville", too! :>

Sorry, that's just *the* image that comes into my head when I think about a candlestick phone! Sitting here, now, I'm trying to think of any *other* instances that could compete and can't think of any!

Ah, no! Maybe "The Munsters" or "Addams Family"? I will have to verify each, though...

Reply to
Don Y

Do most subscriber loops in the US still support pulse dialing? I haven't tried pulse dialing (using the switchhook) lately since I don't have a land line any more -- but, the last time I tried (probably 10 years ago), the switch I was connected to still handled pulse dialing just fine. Actually I've still got a couple phones with mechanical dials and ringers around somewhere...

--
Grant Edwards               grant.b.edwards        Yow! My face is new, my 
                                  at               license is expired, and I'm 
 Click to see the full signature
Reply to
Grant Edwards

Most "real" POTS lines still do, although there are more-and-more "land lines" that are done with VOIP-like technologies, with a traditional two-wire phone interface to support "real" phones. Most of those do not support pulse dialing. Even some telco's are installing such devices for customers. And there are certain restrictions - if you have DSL on the same line, pulse dialing is not possible, for example.

And it's been less than a decade since I've seen a "touch tone" surcharge on POTS line, although I'm not sure it was actually possible to order the line without at that time. But that's how the tariff was written...

Reply to
Robert Wessel

Many phone services these days that support "real" phones no longer support pulse dialing - most VOIP-ish stuff, for example (so if you're getting you "land line" through your cable company, there is value in this approach.

Reply to
Robert Wessel

I meant to mention that a number of years ago I encountered a faux-candlestick phone in a shop, with ten digit buttons arranged in a circle (to visually resemble a dial). What amused me is that there was a pulse/tone switch on the bottom of the phone.

Reply to
Robert Wessel

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.