Sunday, 1 February 2026

Sherwood AX-4050R Repair

[Bear in mind I don't really know what I'm doing here!]

A Sherwood X-4050R amplifier.  Pretty sure it was purchased from Richer Sounds in the late 1990s or early 2000s.    No power at at all - the red standby light wasn't illuminating.

It turned out to be small standby transformer on the power supply PCB: The primary side had gone open circuit.   (Should have been about 1300ohms on that side, based on a 600-and-something measurement from the centre pin.  The secondary side was about 13 ohms if I recall.)

The transformer (kind of dark and cracked on the plastic top) is labelled 2828090901.  You can google but there's not much help.   

Based on looking at the service manual (which is available if you search - though it's poor enough resolution that reading it is a challenge) the transformer needs to supply something like a 13.5v output that will:
a) be used to supply 12v for the purposes of engergising the relay when it's time to switch on properly, and
b) will feed into a GD7806 to supply 6v for the standby circuitry.

Research told me that a 240v primary 9v secondary transformer might be good enough (because it'll give out more than 9v when under the full rated load).  However, finding one that fits was difficult and I couldn't find one with the same pin positions regardless.   The size seems to be an EI30 / EI 30 (the 30 being approximate millimetres).  I skipped over a few that seemed to have obviously bad efficiency ratings (because as a standby transformer it's theoretically going to permanently on) and ended up buying a Myrra 44158.   

It fits in the gap on the circuit board and while the pins definitely are _not_ in the right places, since I was unresolved on any other mechanism to mount and connect it, I tried bending the pins to make them fit to the nearest holes on the PCB.  I managed it - it was definitely one of those times where I felt like I was on the edge of snapping things off - and then when soldering in did a bit of bridging across some of the holes/tracks.  (The board had 3 holes on the primary side and 4 on the secondary I think, but only 2 on each side were used.)

Anyway!  Once fired up, I got a standby light. 

I played some audio into the headphones and was getting some audio distortion.  I was worried that the transformer was underpowered, but managed to take some measurements (on the connector that goes to the front board) of 18v and 6v in standby, and 13v (and a bit) and solid 6v with the amp turned on and powering headphones.  I started playing with the knobs and switches and it seemed to be mostly a dodgy "Direct" (latching push) button.    I didn't fancy my chances of finding matching replacement and figured I could live without the Direct and Loudness options, so I bridged the pins so they were connected in the "off" positions and I desoldered the other leg (hopefully stopping the signal from every also going down the Direct path, say.)

The amp seems to be working nicely.   

I note that the original transformer is marked as a "safety" part in the service manual, which I think means it's part of the device's accreditation and should only be swapped for an exact replacement.  The Myrra transformer is inherently short-circuit-proof and self-extinguishing or something.  It doesn't contain a fuse like the old one (that presumably caused the problem in the first place), but obviously I'm just an amateur playing around with my own equipment for my own purposes here - I'm not saying you should do what I did :-)



Wednesday, 22 June 2022

Windows VPN gives a connection to the remote computer could not be established error.

...and then a helpful "You might need to change the network settings" suggestion.   No other details are provided by the message. 


Of course, you don't need to change the network settings.   The fix for me was the delightfully simple solution 1 on this page:

https://thegeekpage.com/fix-vpn-error-a-connection-to-the-remote-computer-could-not-be-established-in-windows-10/

Basically, delete the miniports in Device Manager then do a scan for hardware changes.  Next connection attempt worked flawlessly.


 

Monday, 28 June 2021

Dynamics 365 CRM "Workflow Expansion" task

 You might see it fleetingly in the System Jobs, or less fleetingly if you end up with a "WorkflowExpansion" Failed job in the logs.

The best explanation for what this task is, even 12 years later, seems to be here:


https://cloudblogs.microsoft.com/dynamics365/no-audience/2009/06/24/microsoft-dynamics-crm-4-0-iworkflowcontext-interface/

To paraphrase:  It's the plug-in that's registered on an entity when you've got one or more asynchronous workflows that are triggered on changes to that entity, and it queries to find out which workflows should actually be run and runs them.

(I'm only looking because we've got some failed entries in the logs.  I guess that means that any workflows that should have been run for the related entity based on that update.... haven't been.)

Thursday, 28 January 2021

SSRS with Dynamics 365 / CRM and multi value parameters not setting their defaults correctly

Scenario:

(Search keywords:  SSRS multi-value-parameter hard-coded values default value FetchXML CRM)

I've created a multi value parameter and manually entered lots of labels/values.

I've gone to the default tab and picked on one of the values.

Copied the changed report up to the CRM using the XRMToolbox ReportSync tool.

Run the report - the default(s) aren't as wished (or in my case didn't seem to have worked at all) so I changed them, re-pushed, and they still don't work.

Issue:  A little exploratory testing seemed to indicate that the CRM isn't paying any attention to changes in the default value(s) when I push the new version of the report up.  (Note that I'm not doing a publish all because there are other users on the system - not sure if that would have made a difference.)

Solution:  Or one, and easy in my case because I'm trying to get the parameter defaults sorted before I've actually used it anywhere:  Change the parameter name and re-push.  (Then change it back again if you want.)  

[There might be other solutions like changing some of the values - not sure.]

Thursday, 13 February 2020

Gen2 2007 Prius Front Right ABS Sensor

So I've bought what I hope is an aftermarket Gen2 2007 Prius Front Right ABS Sensor (wheel speed) off Ebay.

I reckon the correct Toyota part number for this (right-hand-drive) car is 8954247020 or 89542-47020.
This part is made by Herth+Buss and according to the web has part number J5912045 or EAN 4029416234959, but the only number I can see printed on it is on the lead where it says
Herth+Buss 2973600-1019 - a number unknown to Google!

I just stuck a multimeter across the plug's contacts and that gave me an ohm resistance reading of 1.57 ohms.    (I saw a youtube video where the bloke was replacing one - might have been on the Gen3 - and his new one had a resistance similar to mine;  the one he took off measured 2-point-something, I think.)

I'll be getting the garage to fit this soon (when they replace a caliper that appears to be binding and causing some unnecessary heat and some very unnecessary intermittent wheel-squeaking) so I don't know if this is going to fix the problem yet.  (That goes for the caliper too :-(  )
However, the garage told me the wheel teeth are okay, and this part cost me about £40 instead of the genuine Toyota part's £200+, so I figure it's worth a shot.


UPDATE:  Replacement part now fitted and I got the garage to give me the old sensor back.  It registers 1.64 ohms and varies (just a little bit, somewhere less than 0.1 ohms?) when I flash my keys or something else metal across it.   
That doesn't inspire much hope that we've fixed the problem therefore, but what might give me a little bit of hope is that the end of the little metal pin on the sensor does appear to have a little gouge / scratch across it - like it's come into contact with something on its travels.
I'll have to wait till I've taken the car on the motorway to see if it's worked.
(The garage reported that the old caliper was definitely binding, but that pads and disc are still currently okay - so good news on that front.)

FURTHER UPDATE:  I had two problems with the old sensor: the car would shudder coming to a low-speed stop as the ABS decided it needed to kick in and out a bit, even with a gentle slow down (come to think of it, the ABS has always been a little eager to kick in when stopping since I first got the car);  the ABS warning lights would come and and stay on when I got to (let's say around) 70 mph.)   The new sensor has definitely fixed the low speed stopping issue;  however, when I get to (let's say a fast) 70mph the ABS light has still come on.  (It almost always automatically resets after a restart or two, whereas it used to hand around longer than that before.)   My conclusion:  Yep, the old sensor was a bit dodgy, but I suspect there's a small bit of damage to the toothed wheel too - probably should have got the garage to replace that at the same time, regardless of the garage's assurances.  [Mind you - I haven't checked the price of one!]

Wednesday, 5 June 2019

Rank / Execution Order of synchronous / real-time workflows in Dynamics 365

There's a "rank" field in the sdkmessageprocessingstep entity.  (You can see the entity through Advanced Find but you don't seem to be able to access that field, which has a display name of Execution Order.)


I'm using online Dynamics 365 / CRM / Customer Engagement,
Version 1710 (9.1.0.5424) online

XrmToolBox has an "Synchronous events execution order" plug-in that (as of XrmToolBox version 1.2019.2.32 with Synchronous events execution order editor v 1.2016.8.23) lets you connect and set the rank on synchronous workflows (note that they only appear registered on the create event of the entity) but FAILS TO READ the existing rank out of the CRM correctly.

You can confirm the rank has been set by creating a solution, adding your workflow, then exporting.
Customizations.Xml contains (e.g.)
<StateCode>1</StateCode>
<StatusCode>2</StatusCode>
<Rank>50</Rank>
<RunAs>1</RunAs>
<IsTransacted>1</IsTransacted>



[Maybe see also...
https://docs.microsoft.com/en-us/dynamics365/customer-engagement/developer/entities/sdkmessageprocessingstep#BKMK_Rank
and the one sensible answer on
https://community.dynamics.com/crm/f/117/t/154063 ]