Recently I got a 54855A oscilloscope sent back to me for service under the 1 year warranty I underwrote for most of the unit I’ve sold direct. The unit would not turn in at all after sitting for a long time.
I looked up the forum and it turns out other people had this problem with a certain generation of Infiniiums and sometimes changing power supply or motherboard would disturb the setup a little bit and the unit might power on again. When I tried to do that, the unit does boot a quite few times but the problem randomly came back again. This is frustrating as it’s a heisenbug. I almost thought I was done when the unit worked consistently for a week then it comes back. It just looked like something component was acting borderline and disturbing the setup and got it to click.
In the past I had 54830s that’s ‘fixed’ by changing either one of the motherboard or power supply, but turns out that those were flukes, but I didn’t get lucky with 54850s this time.
The customer gave me time to troubleshoot deeper instead of just getting something to work as a fluke by just blindly changing modules which might break down again at a random time if it’s a gravitating aging problem (i.e. if you figured out a problem, it tends to be a wave of manufactured gears that’ll trip on the the same issue as they age). So I spent a whole month troubleshooting through reverse engineering the circuit and nailed down the cause and the fix.
There’s a lot of mixed info going on in the forum with different modes of failure, but those might not be the real cause, as replacing components disturbs a set up that wasn’t supposed to be in that state in the first place and the unit is prone to get trapped into a bad state when the unit ages. The real fix is to plug the path to the bad state in the first place instead of rocking the boat hoping the new combination doesn’t trigger the bad state.
For newer LCR meters where you can label your measurement setups before saving, using the context menu to enter the names is a painful task, and it shortens the life of the keypads. There’s a quicker way to enter it: send GPIB commands (use Agilent I/O) to it. The command is:
DISPLAY:Line "Profile Name 1"
which you can replace the “Profile Name 1” with anything. Keep the double quotes so the parser won’t be confused by special characters such as minus/dash (-) signs.
If the unit supports LXI (i.e. network interface) such as E4980A, so you can send the GPIB commands through network using Agilent I/O Suite.
Architecturally, the DSO6000A series shares common designs with 54830 series oscilloscope and 54640 series oscilloscopes. I noticed the Acq board numbers for my DSO6052A start with 54672 and the my M/DSO6104A starts with 54684. Looks like the 5467X means 500Mhz and 5468X means 1Ghz while the X is the number of analog channels.
This is ‘confirmed’ by a slip up in the documentation (user guide) which they forgot to update the model number in their vector graphics:
I think I’m getting a hang of Agilent’s oscilloscope’s hardware to do deep level board repairs as I have various model to compare. I used If you need yours repaired, please reach me at 949-682-8145.
Got a second customer coming in today with a E507XB series network analyzer that does not turn on. Looks like it’s a common problem within the model series.
If the unit turns on without the CMOS battery but it doesn’t turn on the 2nd time after the CMOS was cleared, you have a very expensive problem which likely I’m the only person who can solve it because it’s months of effort tracing the circuit and the timings inside. I regretted chasing down the rabbit hole and spent more labor than 3 good unit’s costs for the few grands I’ve charged, but I might be able to recoup the labor in the future as more of the E507XB fails the same way.
UNLESS it’s a SC815E (there are 2 revisions that uses different motherboard), it’s NOT the motherboard or the power supply. I’ve seen some faulty SC815E doing the same on other model series, but not the VP22s (I replaced 4~5 different VP22s, they all do the same thing). It’s some good timing issues that’s hard to pinpoint to a specific module (you can replace everything on the digital side and it still doesn’t work) which I had to design, build and test a special circuit to correct it.
If you have a unit E5060 series or E5070 series VNA (Vector Network Analyzer) that doesn’t boot, I’m likely to have the exact experience fixing it. Of course I’m open to solving other problems with the analyzer as well. I offer free eval (no fix, no fee). Please email me at owner@humgar.com or call me at 949-682-8145.
Most often when we sell on eBay, we receive Paypal payments, so we ended up paying eBay’s commissions (also called the final value fee, FVF for short) and Paypal processing fees as a percentage of the sale.
Now eBay pushes out Managed Payments (MP) which combines payment processing fees with the eBay commissions (FVF) because eBay now manages the payment gateway. The rest is every time you sell something, you get a payout (sales – fees) deposited directly to your bank (it used to be collecting paypal balances then withdraw it).
They have a different calculation formula which they claimed the sellers are better off in most cases, but should we take eBay’s word for it? Regardless of whether you are enrolled in managed payments, the fee percentage for each sale depends on:
eBay store subscription level
category
It’s impractical to do the side by side fee structure comparison to see when we are better off for each sale, plus we cannot easily switch between the two plans.
It’d be very helpful if we can put the managed payment fee structure on the same form as the conventional eBay+Paypal fee structure, and figure out under what conditions we are better off or worse off with managed payments.
Initially I was ready to do the derivations to put both plans on the same scale, but I spotted that managed payment (combined) percentage is simply the vanilla (non-managed) eBay category final value fee + 2.35% payment processing fees! That’s how they’ve calculated the combined managed payments percentage!
This makes life a lot easier. Since I can factor out the 2.35% that applies to the whole sum (which also include shipping and sales tax) regardless of the fee cap, this works exactly the same as Paypal (which charges 2.9%) and we are getting a 0.55% discount in payment processing fees.
For managed payments, since we’ve already separated out the payment processing fees, the fee cap applies to the vanilla final value fee portion which is equivalent to the old eBay final value fee. Keep that in mind.
The part that has changed is the fee cap. The old way caps thecommissions/FVF directly regardless of product category, yet the new way (managed payments) caps the sale price that are charged commissions. This means the fee cap goes up or down a little depending on the final value fee percentage class applying to your sale.
eBay set the (commissioned) sale price cap to closely match the realized commission cap in the old way, for example non-store subscriber who will have their raw final value fees capped at $750 will see the same cap for the most common 10% categories (12.35%-2.35% = 10%) because the (commissioned) sale price cap is $7500, which $7500*10%=$750.
Big industrial equipment also have the same cap regardless because $15,000*2% = $300.
For non-store subscribers, 10% is the anchor (iso-fee-cap) category. So you are a little worse of with books (price cap +2%) and better off with musical instruments (price cap -6.5%).
For store subscribers, you get a bit more break over the fee-cap (lower) because your final value fee percentage is lower than the anchor (likely they chose a breakeven point at 10% when determining the sales price to cap final value fee over. Just easy numbers, not rocket science):
Managed
Conventional
Discount*
Common (9.15%)
$2,500*9.15% = $228.75
$350 (Small stores)
$250 (Big stores)
$121.25 (Small stores)
$21.25 (Big stores)
Heavy gears (1.5%)
$15,000*1.5% = $225
$250
$25
Books (12%)
$2,500*12% = $300
$350 (Small stores)
$250 (Big stores)
$50 (Small stores) -$50 (Big stores worse off)
Guitars (3.5%)
$2,500*3.5% = $87.5
$350 (Small stores)
$250 (Big stores)
$262.5 (Small stores)
$162.5 (Big stores)
I call Basic/Premium ‘small-stores’ and Anchor/Enterprise ‘big-stores’.
So here are the observations, which is all you need to know:
Under managed payments, small-stores gets a better deal than big-stores, because the advantage of the $100 lower fee cap with big stores are eliminated with variable fee caps.
The breakeven line for small stores ($350 cap) is 14% fees ($350/$2500), which the highest category is 12% so far. This means small-stores are ALWAYS better off switching to managed payments.
The breakeven line for big stores ($250 cap) is 10% fees ($250/$2500), which the only category above that right now is books (12%). Big-stores selling BOOKS are worse off with managed payments.
So in other words,
everybody is better off with managed payments (fee-wise) EXCEPT big-stores selling books
under managed payments, there’s no final value fee advantage for being a big-store
* Remember you got 0.55% discount over the payment processing portion of the fees too and is not shown here since we’re just talking about savings in vanilla final value fees.
As far as books (12%) is concerned, if you are a big-store owner, your raw commissions cap raised from $250 to $300 because $300 = $2500 * 12%. But if you factor the 0.55% discount, if the sale price is $x,
Since the raw commissions stops at $300 ($2500 * 12%), the additional $50 cap increase starts to get offset (and turn out positive as the processing fee discounts outweighs the commissions cap increase) when the payment processing discounts ABOVE $2500 covers all of it:
So the range of sale price x which the only setup (books for big-store sellers) can do worse is
There are some ambiguities (technically incorrect documentation) on eBay’s website which implied vanilla final value fees (portion) are charged for sales tax. I made a sale and checked the numbers and it’s not true. Only the 2.35% payment processing fee portion is charged against the sales tax (like paypal for handling extra money), the category final value fee (in my case 9.15%) is not applied to the sales tax.
They actually meant “the 2.35% payment processing fee portion” when they said “managed payment final value fees”. This is also part of the reason why I wrote this article, because they do not use the language that conceptually separate the two portion of the combined final value fees (vanilla final value fee + payment processing fee) in managed payments, thinking that they are simplifying the math for sellers, without realizing if the two concepts really fused into one, they’ll be shortchanging sellers over sales tax.
The $0.3 fixed per-transaction fee applies to both managed payments and the conventional way (Paypal also charge +$0.3 fixed per-transaction), so nothing has changed.
