Background

Quite a few years ago now I joined the “time-nuts” mailing list – a “Time Nut” as the gentle reader may be aware is an individual who tinkers with precision time keeping and/or precision frequency references, measurements and the like for hobby interest.  It’s a great list, always an interesting discussion and very high SNR indeed – fun place to virtually hang out.

Through this I became interested in playing around with some precision references at home and this in turn lead to me picking up a couple of Rubidium frequency standards off eBay from a local seller – one known working, the other known faulty.  These devices are usually ex-mobile phone base station installations where they’re commonly used to provide a precision 10MHz reference signal to drive the timing circuitry of the base station itself.  They’re usually a secondary source, the primary being a GPS Disciplined Oscillator (GPSDO) – the Rb standard is a hot spare in case the GPSDO goes out of lock for too long.

The Efratom SLCR-101

The SLCR-101 is made by US firm Efratom (now part of Symmetricom by way of Datum best I can tell) and is designed for OEM applications – so it’s basically a bare module that you feed power into and it gives you a nice clean stable 10MHz sinewave output as well as some status signals.  I’ve been unable to find any specific data on the SLCR-101 but it seems very similar indeed to the LPRO or LPRO-101 units – just lower profile – about 25mm/1″ high versus the LPROs 38mm/1.5″ height.

A bit of searching turns up a PDF of the LPRO-101 “User’s Guide and Integration Guidelines”.  Another document to seek out is Fred de Vries “Efratom LPRO-101 Repair Reference Guide”  The most recent revision of this excellent reference seems to be Revision 7, January 2011 – Fred kindly sent me an email with the latest version of his guide which, with his permission, I’ve placed here.  I am trying to find a definitive upstream source for the offical LPRO document, for now a little googleFu will get you there.

One immediate take home from these documents is that these units must not be operated for extended periods (say more than a half hour) without a proper heatsink (less than 2C/W thermal resistance to ambient) – the Rubidium lamp inside runs at around 100C so good heatsinking is required to ensure the rest of the electronics is kept within its safe operating temperature.

Disassembly

Removing the cover wasn’t difficult – I’ve a bunch of photos shared here but in particular this one shows a unit mounted on a heatsink and this one how once the connector assembly is removed (undo screws, break the slight sealing and pull straight out) With the connector removed, the cover can simply be eased up with a flat blade working around the perimeter of the casing.  Note that the unit will not operate properly without the Rubidium lamp assembly being shielded from AC lighting.  Perhaps also worth noting that you don’t need to disassemble the unit unless it’s faulty or you’re curious :)

Internals

The internals are well covered in Fred de Vries document, but by way of a quick “cooks tour”, referring to this photo; The rubidium lamp assembly is the machined section top left – lamp in the brass coloured section, photodiode etc. in the right hand side.  Slots in the PCB are to accommodate a shielded section that fits over the lamp as visible in this picture.  The cylindrical port in the top left of the shield photo is used to gain access to the frequency trimpot on the control PCB (blue, bottom right in this shot).

Close

Will have more to write on my tinkering with these units in subsequent posts – for now hopefully the little note about how to remove the connector will save someone some time :)

Edited 20170423 to include link to the repair guide kindly provided by Fred de Vries.

I did a little rewiring of my keyboard rig on the weekend, in particular the pedal board I use to keep things organised and quick to set up.  In the process of this I loomed three of the foot switches up together which necessitated re-terminating them with new plugs having cut the old ones off.

For future reference then, here is the wiring schema/colour codes for my particular pedals.  If Google picks this page up, might save someone else a little hassle :)

Yamaha FC4 Footswitch

The FC4 is a conventional switch, Normally closed, contacts open when the pedal is pressed down

• Tip – N/C Contact – Inner conductor in cable
• Sleeve – N/C Contact – Shield in cable

Yamaha FC5 Footswitch

Electrically the same as the FC5, just a different physical form factor.

• Tip – N/C Contact – White conductor in cable
• Sleeve – N/C Contact – Black conductor in cable

Yamaha FC7 Footpedal

So with the FC7 footpedal, when it’s pressed all the way down, the minimum resistance (100 ohms or so) is between the ring and tip, and maximum resistance (50k ohm approx) between ring and sleeve.  When the pedal is all the way up this reverses – the minimum resistance is between the ring and sleeve and maximum resistance between the ring and tip.

• Tip – “Down” end of 50k ohm pot – White conductor in cable
• Ring – Wiper of 50k ohm pot – Red conductor in cable
• Sleeve – “Up” end of 50k ohm pot – Shield of cable

As I mention elsewhere in the pages I’ve been playing keyboards on and off for over 30 years now, a passion that came about from being interested in electronics and computers first, then wondering how to make music with them second.

So anything that combines the two is bound to be a bit of fun in my book.  I did just that this morning and thought would post what I learned along the way – might be of interest to others and I’ll know where to find it too :)

Back in about ’87 or ’88 I had a keyboard rig that used two Yamaha KX-76 controller keyboards – for anyone unfamilar these are keyboards that just produce a MIDI data stream that in turn goes into some other device to create the actual sounds.  To this day I’ve still got the two KXs and consider them one of the better feeling “synth action” keybeds out there.  A little noisy acoustically – so perhaps not ideal in a studio setting, but for band work ideal.  In any case, I digress…

Like most keyboards the KX-76s are velocity sensitive – the harder/faster you press, the louder the sound.  Velocity sensitivity is generated by firmware in the keyboard by working out how quickly the key has been pressed.  In practice this is usually accomplished by each key having a pair of switches (or a single leaf style switch with two positions as is the case in the KXs) that are set up so they change state one after the other as the key moves.  Time how long it is between the first one switching and the second one and you have a figure that can be turned into velocity.

The above is all stuff I’ve understood intuitively for some time, but I’ve often wondered just how quick this time interval between the two switches is – one day I’d like to build a controller of my own and this is a fairly important design consideration.  So this morning with a bit of tinkering around I was able to do some experiments to find this out – hence the setup in the photo above.

Turns out the shortest interval is around 5ms up to 20ms+ for a very slowly played key.  Anything over about 10ms seemed to be interpreted as the “minimum” velocity of (0x01).  I couldn’t manage an interval of less than 5ms or so – this corresponded to a velocity of 105 which is the maximum a KX-76 will send anyway (this a throwback to limitations of the original DX-7 as I recall which also stopped short of the 127 maximum velocity).  Also a fair bit of “keybounce” for a ms or so after contact close/open.

Key up time was 9ms if the key was allowed to return to it’s original position via the spring.

Screen capture below is typical for a mid-velocity press.

One other detail I should add – the keyboard in the KX-76 is a matrix with notes as columns and octaves as rows.  It’s scanned by the microcontroller on the main board such that each note is checked once per millisecond. The scanning appears to stop until the key down time is captured, then continues.

Oh and yes, the KX-76 survived the ordeal of being poked and prodded :)