While attempting to repair a B&K 8500 that wouldn’t draw low currents (but would draw high currents), I drew the following schematics.

Some components and values are definitely missing – I only drew what was related to the problem I was having. The power supply, comms, microcontroller, ADC, DAC, reference, etc. are all missing.

Hopefully these diagrams will help someone else who is repairing one of these electronic loads.

Some notes in no particular order:

• TPA is measured current – voltage at top of range is the same for 0-3A range as it is for 0-30A range.
• TPV is measured voltage – note there is a 2nd voltage divider feeding the ADC, thus voltage is measured in two ways/places.
• TPK is the final output from the current/voltage control section, that will feed the FET driver circuits.

StubHub appears to be using Apigee, just like Ticketmaster… Go figure.

{"fault":{"faultstring":"Unexpected EOF at target","detail":{"errorcode":"messaging.adaptors.http.flow.UnexpectedEOFAtTarget"}}}

It looks like an issue between Apigee and StubHub, nothing we can do. Catch this error and retry.

Let’s say you want to log into a webpage using PHP.

You post the login credentials to the login form, and expect to get a cookie back.

But you get this back instead:

Hmm. Well, the message says we need to enable Javascript. So let’s do what it says!

Following the instructions here, we can install the V8 Javascript engine, and v8js, a PHP interface to V8.

Then we extract the text between the <script/&#x3E tags, and feed it to V8.

By callling V8Js::executeString, we can run the Javascript we got back, then print whatever cookie it’s eventually generating. All we need to do is stub out `document` and `location.reload()`. We can find this either by running the code and watching the error messages, or base64-decoding the above string to get an idea of what it does.

An example PHP script might look like this:

On running the example script, you would see an output like this:

sucuri_cloudproxy_uuid_a9ab87baf=990a10f6524c47082cf1bb8bb6faa83b;path=/;max-age=86400

And that’s it! By passing this cookie, we will be considered logged-in.

A 404 page is returned when any POST request is sent to “/xmlrpc.php” on A Small Orange-hosted WordPress sites:

GET requests work as expected:

But if we rename “xmlrpc.php” to “2xmlrpc.php” then POST requests work:

If you ask Sales, they will tell you that they do support XMLRPC:

Can’t really blame the rep, they are just following a script.

idk. We will just rename xmlrpc for now. Hope this helps someone else.