Turn your Rigol DS1052E Oscilloscope into a 100MHz DS1102E
in [Design]
|
From: Joel Koltner on 5 Apr 2010 23:06 <krw(a)att.bizzzzzzzzzzzz> wrote in message news:bu7lr590c1dnnvm35bph3iv82ukthv3494(a)4ax.com... > As do we. Our upper end base unit does have a couple of bucks worth of > op-amps that the less expensive model doesn't have but the mobile units are > identical except for the firmware. ....and I'm guessing that when you plug a mobile unit into a PC via the mini-USB connector, at least you guys used your own vendor/product ID so that even if you are just using, e.g., an FTDI chip in there, Windows doesn't "conveniently" install the serial port driver for you! (We do that on our products, not because we have anything to protect, but just because it's a lot easier when troubleshooting with customers to tell them to look at "XYZ Corp USB Widget" rather than a generic "FTDI serial port" or whatever and we know exactly which version of the drivers our "XYZ Corp" install disk is using whereas Windows tries to be smart and updates them from time to time, which on occasion can cause problems.) We have a multi-slot charger that has the ability to send programming parameters, update firmware, etc. to a unit in any one of the slots, but we officially only support programming in slot #1 (and the slikscreen even says, "programming, this slot only" on it) -- this happened after a long internal debate over whether or not end-users were, um, "sophiticated" enough to get some benefit out of being able to program in any slot vs. the extra support calls from those who were telling the software to program a unit in, say, slot #6 when they'd actually inserted their unit into slot #3 and couldn't figure out why they kept getting error messages. The "this could be a whole lot of extra support problem" argument eventually won out. There is, however, a magic phrase you can type to "unlock" the ability to program through any slot -- all the hardware and software to make this happen was done by the time the internal discussion had been settled. The manufacturing guys use this so that they can just load up all the slots with units, they start loading new firmware, and by the time they finish loading the last slot, it's usually been long enough that they can go back and remove the first on and keep going. > This was mentioned before, but I worked on the crypto stuff that IBM used in > their mainframes to enable processors based on customer payments. If they > needed more compute power for year-end statement processing (or whatever) > they'd pay for more CPUs and the key to use those computers, for the time of > the payment, was sent to the crypto unit to unlock the processors. That's a pretty good model. ---Joel
From: John Larkin on 5 Apr 2010 23:10 On Mon, 05 Apr 2010 21:49:41 -0500, "krw(a)att.bizzzzzzzzzzzz" <krw(a)att.bizzzzzzzzzzzz> wrote: >On Mon, 05 Apr 2010 18:23:24 -0700, John Larkin ><jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote: > >>On Mon, 5 Apr 2010 18:53:51 -0500, "George Jefferson" >><George(a)Jefferson.com> wrote: >> >>> >>> >>>"John Larkin" <jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote in message >>>news:q90kr5pda1mtti9pea5c7tqmao0u9qvfpi(a)4ax.com... >>>> On Mon, 5 Apr 2010 14:42:48 +1000, "David L. Jones" >>>> <altzone(a)gmail.com> wrote: >>>> >>>>>John Larkin wrote: >>>>>> On Fri, 2 Apr 2010 20:23:54 +1100, "David L. Jones" >>>>>> <altzone(a)gmail.com> wrote: >>>>>> >>>>>>> For those who thought Rigol may bin the scopes to get 50MHz and >>>>>>> 100MHz models, and that they aren't actually identical hardware and >>>>>>> firmware, I've been informed that Rigol have finally admitted this >>>>>>> to an irate customer who contacted them about the issue. >>>>>>> >>>>>>> Partial Quote from Rigol : >>>>>>> "The firmware of the instruments is made >>>>>>> to enable capability based on the version purchased just like any >>>>>>> software licensed product you would buy." >>>>>>> >>>>>>> Betcha they would never have admitted that before it was all exposed >>>>>>> a few weeks ago. >>>>>>> >>>>>>> Dave. >>>>>> >>>>>> Too bad that, with all this ranting, this thread is missing a couple >>>>>> of interesting technical issues re: the varicap bandwidth limiter and >>>>>> the compromises it forces. >>>>> >>>>>I find that funny considering it was you who started the ranting and also >>>>>continued it ad nauseam. >>>> >>>> Not so. I pointed out a possible legal issue, and brought the >>>> interesting but unresolved issue of how one amortizes and prices >>>> things, like firmware, that have no incremental cost to manufacture. >>>> Most perple here seem to feel that it's a ripoff to charge for such >>>> things, and a minority feel, as I do, that Rigol did nothing wrong and >>>> provides very good price:performance for both models. Rigol is like >>>> someone who used to leave their front door unlocked, until someone >>>> wandered in and stole something, so now they have to lock it. >>> >>>They did nothing wrong. They had identical products(or all intents and >>>purposes) but slapped two different labels on them and charged different >>>prices for generating revenue. >>> >>>DIFFERENCE BETWEEN US? You think that's ethical. >>> >>>http://en.wikipedia.org/wiki/False_advertising >> >>What did Riogol do that was false advertising? As far as I know, both >>scopes deliver more bandwidth than promised and both are excellent >>values. Their features blow away the low-end Tek scopes that cost 2x >>or 3x as much. >> >>I sell versions of products that differ only in enabled features. So >>does practically anybody who sells products whose performance depends >>on firmware and other IP that was expensive to develop. > >As do we. Our upper end base unit does have a couple of bucks worth of >op-amps that the less expensive model doesn't have but the mobile units are >identical except for the firmware. There are more protections to prevent >upgrading than Riogol used, however. > >This was mentioned before, but I worked on the crypto stuff that IBM used in >their mainframes to enable processors based on customer payments. If they >needed more compute power for year-end statement processing (or whatever) >they'd pay for more CPUs and the key to use those computers, for the time of >the payment, was sent to the crypto unit to unlock the processors. A complete >complement of processors was shipped in every box and only the software >configuration determined how many the customer could use (two to ten). As a >bonus, if one processor fell over another would pick up where it left off with >no additional payment required. I guess that was fraud, too. > I think the cut here is that amateurs, who penny-pinch on gear, are outraged by Rigol's actions, and professionals, who design and buy and sell electronic instruments, think they are being perfectly ethical and reasonable. The amateurs mostly don't need a 100 MHz scope anyhow, and should be (and aren't) grateful that Rigol sells the 1052 for around $500. I bought the 50 MHz version to use in my office because that's fine for most uses. John
From: krw on 5 Apr 2010 23:18 On Mon, 5 Apr 2010 20:06:20 -0700, "Joel Koltner" <zapwireDASHgroups(a)yahoo.com> wrote: ><krw(a)att.bizzzzzzzzzzzz> wrote in message >news:bu7lr590c1dnnvm35bph3iv82ukthv3494(a)4ax.com... >> As do we. Our upper end base unit does have a couple of bucks worth of >> op-amps that the less expensive model doesn't have but the mobile units are >> identical except for the firmware. > >...and I'm guessing that when you plug a mobile unit into a PC via the >mini-USB connector, at least you guys used your own vendor/product ID so that >even if you are just using, e.g., an FTDI chip in there, Windows doesn't >"conveniently" install the serial port driver for you! Sure. Didn't you try it? The TI DSP runs the USB port. >(We do that on our products, not because we have anything to protect, but just >because it's a lot easier when troubleshooting with customers to tell them to >look at "XYZ Corp USB Widget" rather than a generic "FTDI serial port" or >whatever and we know exactly which version of the drivers our "XYZ Corp" >install disk is using whereas Windows tries to be smart and updates them from >time to time, which on occasion can cause problems.) >We have a multi-slot charger that has the ability to send programming >parameters, update firmware, etc. to a unit in any one of the slots, but we >officially only support programming in slot #1 (and the slikscreen even says, >"programming, this slot only" on it) -- this happened after a long internal >debate over whether or not end-users were, um, "sophiticated" enough to get >some benefit out of being able to program in any slot vs. the extra support >calls from those who were telling the software to program a unit in, say, slot >#6 when they'd actually inserted their unit into slot #3 and couldn't figure >out why they kept getting error messages. Never foolproof anything. All you do is create bigger fools. >The "this could be a whole lot of extra support problem" argument eventually >won out. > >There is, however, a magic phrase you can type to "unlock" the ability to >program through any slot -- all the hardware and software to make this happen >was done by the time the internal discussion had been settled. The >manufacturing guys use this so that they can just load up all the slots with >units, they start loading new firmware, and by the time they finish loading >the last slot, it's usually been long enough that they can go back and remove >the first on and keep going. Good idea. It also kicks the decision whether to support all slots down the road as far as possible. I don't like painting myself into a corner either. >> This was mentioned before, but I worked on the crypto stuff that IBM used in >> their mainframes to enable processors based on customer payments. If they >> needed more compute power for year-end statement processing (or whatever) >> they'd pay for more CPUs and the key to use those computers, for the time of >> the payment, was sent to the crypto unit to unlock the processors. > >That's a pretty good model. It solved a *lot* of problems. The development team referred to it as "Dial-A-MIP". ;-)
From: Joel Koltner on 5 Apr 2010 23:52 <krw(a)att.bizzzzzzzzzzzz> wrote in message news:uc9lr5ltlkvvo4g79m19ebgm68c3srgbu0(a)4ax.com... > Sure. Didn't you try it? The TI DSP runs the USB port. No. We had them for a long enough time that we could have, but had a rather rushed evaluation as we'd just let them sit around for a few days and then got an unexpected call from the place that had loaned them to us... telling us we had them return them in the next day or two, as they had an Actual Paying Customer who needed them for a show. Hence our evaluation was confined to playing with the base station and belt packs; we didn't plug a computer into either of them. Still, in that limited period of time lots of nice things were said about them-- in general they work quite well, certainly; they're a huge improvement over the old wired "party line" style intercom system I used in stage crew some decades back! > Good idea. It also kicks the decision whether to support all slots down the > road as far as possible. I don't like painting myself into a corner either. Yep, agreed. I've known programmers and designers who get way too hung up on, "I have to know exactly EVERY LAST BIT of a spec before I can do ANYTHING," and they're just no fun to work with -- especially given how I've never worked on a project of any significant complexity where there weren't various spec changes between the beginning and end of the project anyway. ---Joel
From: krw on 6 Apr 2010 00:02
On Mon, 5 Apr 2010 20:52:44 -0700, "Joel Koltner" <zapwireDASHgroups(a)yahoo.com> wrote: ><krw(a)att.bizzzzzzzzzzzz> wrote in message >news:uc9lr5ltlkvvo4g79m19ebgm68c3srgbu0(a)4ax.com... >> Sure. Didn't you try it? The TI DSP runs the USB port. > >No. We had them for a long enough time that we could have, but had a rather >rushed evaluation as we'd just let them sit around for a few days and then got >an unexpected call from the place that had loaned them to us... telling us we >had them return them in the next day or two, as they had an Actual Paying >Customer who needed them for a show. Hence our evaluation was confined to >playing with the base station and belt packs; we didn't plug a computer into >either of them. > >Still, in that limited period of time lots of nice things were said about >them-- in general they work quite well, certainly; they're a huge improvement >over the old wired "party line" style intercom system I used in stage crew >some decades back! There's a rather major announcement/demonstration coming at NAB next week. It's "only" firmware, but it's really cute. Did you notice that our partner was bought out? ...a little scary. >> Good idea. It also kicks the decision whether to support all slots down the >> road as far as possible. I don't like painting myself into a corner either. > >Yep, agreed. I've known programmers and designers who get way too hung up on, >"I have to know exactly EVERY LAST BIT of a spec before I can do ANYTHING," >and they're just no fun to work with -- especially given how I've never worked >on a project of any significant complexity where there weren't various spec >changes between the beginning and end of the project anyway. I don't like the opposite either; no specs - wing it. Whatever happens it's then the engineer's fault for having a defective Ouija board. |