I don't know about Rigol but I imagine Agilent is a heavy advertizer in your publications. Is it wise to publish methods for hacking / bypassing the upgrade process on their products? By bypassing their sales process you reduce their revenue which eventually makes it into the ad budget. This article covers inexpensive products but the precedent scares me a little...
I could see them being upset if maybe we uncovered something new that might impact them in negative ways. They are fully aware of these things already and at this point, these upgrades can actually serve to make some older models more attractive if they are found.
I wonder what these companies do if you return the unit for service and in the process of doing the repair they discover that you've activated functions that the original model didn't have? I would imagine in many cases from that point on your warranty is null and void because of the "non-authorized" nature of your "repair". I would also tend to think they would be wiithin their rights to just declare the entire main board was defective and max out both the parts and labor components of your repair (maybe even replacing these boards with "non-upgradeable" models) since now you're on the hook for the entire ball of wax! What if you regularly send the unit out to metrology, wouldn't they be inclined to "rat out" your little "upgrade" to the OEM too (since now there could be more functions to calibrate so higher costs for them to bear)? Or I suppose you could undo the repair before you sent it in and redo it after it comes back...
This reminds me of a situation that used to exist in the old mainframe computer days where nothing was ever purchased and everything was on lease by the month, service included. So there was one model of processing system which was frequently field-upgraded to a higher-performance model by replacing all the circuit cards which frequently took a process of several hours during which all the boards were removed and taken out, then a different crew came out and installed all the new boards. The truth of the situation turned out to be that the cards were all the same EXCEPT for a divide-by-two jumper in the master clock chain, the rest of the procedure was simply "choreographed" to demonstrate to the customer how much value he was getting for his much higher lease rate! On the rare occasion that a customer discovered the charade (generally after it was divulged by a "rogue" employee of the computer company) the purpose of the existence of the two models and lease rates was "justified" by the higher speed at which the printer components had to operate for the higher-performance model which resulted in much higher mechanical service costs (I guess you had to have been there but the justification really wasn't all that unreasonable). Now in THAT situation an unauthorized "field upgrade" would definitely NOT be ignored (I believe there was an OS function that even identified the machine as being the higher-performance model)!
JeffL, I think you may have hit on the real reson for the SW lock on BW, from a calibration perpective whether you cal out to 50MHz or 100MHz may be enough effort to justify a modest price difference as indicated. I have a Tektronix MSO and they have protocol decoding add-ons that are ~$1500 and have no calibration repercussions. Personally I find it stupid because I'm sure less than 1% of people buy an expensive "Upgrade" for protocols where as if they charged an extra $100-$200 and included it all they would sell a hell of a lot of scopes. Even if they made the add-ons $50-$100 they would make more money, because as it is I purchase a $150 separate protocol analyser from a different company and they don't make a cent.
Well, the reason why I write this title down is exactly how I think about the sales method with 'soft options'. I hate it. Maybe this might work for the 'average people', but if it works for engineers, I have my doubts. Well, at first, let us assume the hardware is there. No add-ons needed, that's where we are dealing about. right?
My thought then is: That stupid company did not sell a big bunch of their equipment, because they have hidden it's features in the closet. While it already has been developed, engineering hours have been spend, so, WHY THE HECK DONT YOU ALWAYS SELL IT WITH IT THEN? JUST GIVE IT AWAY !!!
That has been said. And I will assure everybody here that the sales quantities certainly will go up, paying for the development anyway. And for logistics, lots easier too, saving lots of money again. Maybe it is time for a poll if engineers want this or if they want to buy for each stupid option or silly trigger method. Personally I think these times are over.
Navelpluis wrote: My thought then is: That stupid company did not sell a big bunch of their equipment, because they have hidden it's features in the closet. While it already has been developed, engineering hours have been spend, so, WHY THE HECK DONT YOU ALWAYS SELL IT WITH IT THEN? JUST GIVE IT AWAY !!!
Here's an example of why you (the vendor) want to have hidden features. Let's say you have two products A and B, where B is an upgraded version of A that the same except for more software features and more cleverness in the FPGAs. In addition, B may include licensed software from another vendor for which you pay per-unit royalties. It costs exactly the same to make A and B hardware.
Here's the issue: you somehow need to pay for the development and support of B, which is more costly than A. If you have only one model and price it high, a customer who only needs the capabilities of A will buy a cheaper product C from another vendor. If you drop the cost of your one model to compete with C, you won't make enough money to pay for the development of B.
Solution: Price model A cheaper than C, so you get that market. Price model B more expensive than C, but people who need the additional capabilities are willing to pay for B because other vendors' products D, E, and F are more expensive. You do need a secure way to upgrade A to B, otherwise customers will buy A and then upgrade it to B without paying the difference.
One way for equipment companies to make the upgrades harder is to sell hardware keys. No key, no upgrade. But the keys were being hacked in China and sold at lower prices than the company was charging. The company responded by using data encryption.
I get your point. The royalties issue can be a problem, however, it is the choice if you want this in your business-model yes or no. We never do this, or we pay royalties on product quantities. And if you pay on product quantities I mean all products, hence, ony 1 type of product exists doing the broadest things for all our customers. Everybody is happy, including the IP owners.
Here's another issue: product complexity. In the example I'm thinking of, the full-blown product that does everything is like a Swiss Army knife with hundreds of thingummies, which easily confuses customers as well as sales and support staff. So in this case, Model A is not only cheaper, but easier to understand since it has fewer thingummies.
Different companies serve different markets and have different needs, so YMMV.
The company I currently work for does not do this, but we have thought about it. Here's the reasoning:
There is a lot of manufacturing cost involved in making the 2 models, while the actual material cost isn't as significant. Therefore, it makes sense to just make one hardware version. Suppose we sell this "all-in-one super model" instead of some software-locked version.
Customer: "Well, I don't want all those extra features, I just need the basic stuff" Me: You're getting everything at the same price, you're not paying extra, trust us. Customer: How can it be that less features doesn't cost less? I don't believe you!
So at this point we'd be stuck, you can drop the price, but then the next guy will the say the same thing until you're no longer making money. The only way you can "win" is if your model over-specs and under-prices the competition significantly. That would be a dumb assumption unless for some reason you are the only holder of the "secret sauce" and the other guys have dumb engineers or something like that.
Depending on what kind of equipment you make you certainly have a point. Regular consumers respond like this. Buy hey, you have to agree that we are talking about my example so silly that it makes you laugh: Pay an extra for CANbus triggering, pay extra even for I2C triggering, pay extra for some speed that is already in there, pay extra for FSK modulation in your RF generator. It is already in there and every engineer wants it, so it has been developed, hours has been spend, again I say GIVE IT AWAY ;-)
I have a Tektronix MSO and they have protocol decoding add-ons that are ~$1500 and have no calibration repercussions. Personally I find it stupid because I'm sure less than 1% of people buy an expensive "Upgrade" for protocols where as if they charged an extra $100-$200 and included it all they would sell a hell of a lot of scopes. Even if they made the add-ons $50-$100 they would make more money, because as it is I purchase a $150 separate protocol analyser from a different company and they don't make a cent.
Why won't they realise their mistake? Because a marketroid would have to admit they're blithering idiots.
My second-favorite example of this was a computer from the 1960s or 1970s which was microcoded, a common way of implementing an instruction set in the days of slow core memory. They sold different models, charging more for the higher-performance models. The only difference is that the low-performance models had extra NOP instructions in the microcode to slow down execution. Otherwise, the machines were identical.
My favorite example is an IBM card reader. They had two models, one twice as fast as the other. You could actually get a field upgrade from the low-speed to high-speed version. The IBM tech came in with a big toolbox and removed a panel to expose the mechanism. Then he looked around to see if anyone was looking and quickly moved a rubber belt from one set of pulleys to another :-)
[Both stories were heard from other people, so may be aprocryphal. But they pre-date the Internet, so they must be true.]
.. you never know if the manufacturers did something that can cause damage if you unlock hidden features. As an example, a small hack could could cause some pll to run at higher frequency, overclocking the system to a level where it requires different physically cooling. Also the cheaper model could be equipped with chips with worse timespecs (like slower memory) wich mostly works, but not guaranteed.
This will of course be at your own responsibility, but as a group, a bunch of "hackers" can make it work by trying and failing (or even analyzing).
Morally, this will maybe at worst end up at some grey zone. But, imho, if manufacturers dont want it to happen, they better put some effort into preventing it.
I've developed systems with this function myself, but to unlock you had to unprotect a flash sector using hard wiring and then program the correct key for its serial number. The reason was simply to sell more and maybe get some upgrade orders. But the effect of what we did remains unknown.
I guess this is not as valuable as it was, but once-upon-a-time, I found that ALL "4-banger" calculators have the "1/X" (reciprocal) function built-in, in one of two versions: Once a number is displayed, pressing "divide" "equals" presents the reciprocal on most machines, and pressing "divide" "divide" "equals" does on all. But not on "Scientific" models. Apparently the code/algorithm was developed only once or twice! Back then, this was the most useful missing function.
Some calculators even had an extra pair of contacct-fingers on the board that would invoke square-root if an extra button were kluged-in.
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.