A few weeks ago I saw a nifty little 8 inch long 120 volt extension cord.

Rather than the usual application of an extension cord, these were used to get several "wall warts" plugged into a single outlet strip / surge protector.

The fellow had 6 of these really short 120 volt extension cords plugged into the outlet strip, with 6 wall warts plugged into the end of them like a bunch of fat puppies nursing on a mama dog.

I can't seem to locate these things, and my shack is being overrun by these oversized transformers that take up several spaces per unit.

Does anyone have a URL or company name, address, etc. where I can get some of these things?

I've built a couple, but only had a pair of extension cord pieces in my junk drawer, and I don't want to spend full price on cord plugs and sockets to build em at $3 to $5 a pop.

The fellow who had them said he paid maybe $10 for about 15 units at a swapfest.

If nothing else, I'll buy a couple hundred of them and see how many I can sell at HamCom :-)

I have a TM721 dual band mobile rig that drops out on 2 meter transmit when the unit is above about 70 degrees Fahrenheit. It still transmits fine on the 70cm band.

Detailed symptoms are that it will transmit with proper power for an interval between milliseconds and seconds, usually dropping the carrier as if it were un-keyed.

Re-keying the mike will usually bring it back up for a brief time.

The power level does NOT progressively dip with temperature - it either keys or it spontaneously un-keys in mid syllable, and experiments with a heat gun (and temporarily swapping thermistors with fixed resistors) have pretty much proven the problem is not in the final amplifier "brick".

The fact that in cold weather it is possible to yak on the thing at high power long enough to get the heat sink quite hot to the touch without any failures suggests that the failure is not thermally connected to the chassis.

So the radio operates quite reliably in the winter, but with the coming of spring and summer, the 2 meter side is totally useless even when the windows are left open in the car to limit temperatures.

I've seen tech bulletins about arcing coils, and a few other stray ones from Kenwood (and now probably out of print), but nothing to address this specific problem.

I'm hoping someone has encountered this before, as about the only way I can think of to find it would be to build an environmental "warm box" with a big supply of circuit chiller to systematically heat / cool components until it can be found.

The almost precise temperature threshold where the failure mode occurs has been baffling me for the 8 years I have had the radio, and it repeats every single season.

Or maybe I ought to get a small refrigerator / freezer and inverter and install the rig in there during the summers - LOL.

Hmmm. What about some of those ultra-bright yellow or orange LEDs with current set / limit resistor instead of incandescents?

Now to take one of the rigs off line to go in and see how hard it is to replace / upgrade the lights, as well as mechanical mounting issues.

I've noticed since the previous post that more lamps have gone out in all 3 of the rigs, so the APRS tracker in my car has gone totally dark.

A related idea is using these ultra-superbright LEDs to upgrade the illumination in a couple of other radios that have some critical buttons very hard to read in the dark. The wife's Alinco DR-590 comes to mind, as does a Kenwood TM721.

> Posted By N7JAU
>
> I don't know exactly what you are trying to do, but
> the hardware may just be in place already. First,
> realize that not all Motorola bagphones are

I'm specifically trying to emulate a handset with a microcontroller, to open the door to other interfacing.

As to the pinout and codes, there appears to be a "pool" of codes between handset and transciever, which different models of the bag phones use a subset of with a few that are common to all.

A good analogy would be the IBM PS/2 and AT keyboards. I have a "generic" keyboard which works fine on my E-machine, but the keyboard that came with it has a whole bunch of extra special function keys that only the E-machine understands.

However, I can plug the E-machine keyboard into the Acer, and the standard QWERTY keys work just fine, although the Acer chokes on the extended keys.

But there is a common signal protocol involving timing and bit stream contents that correspond to all of the standard characters that is shared by all PC/AT computers regardless of manufacturer.

This standard is published somewhere, to a sufficient extent that one could write code for a PIC processor to emulate a computer keyboard, enabling a Wintel box to be booted and operated with the PIC emulator plugged in, fooling the computer into thinking it is
talking to a keyboard.

There is also a standard that exists somewhere for the Motorola bag phones that defines the communication protocol between handset and transciever. There must be  "common denominator" to these serial codes because handsets can be interchanged among different models with limited functionality, at least on the service bench.

At least one outfit does make a "POTS" interface for most of the Motorola bag phones, both the AMPS only (circa 1994/95) and the PCS capable units. The problem is, this thing is 1) too expensive, and 2) requires more circuitry to deal with the POTS emulation.

Instead I'd rather directly talk to the transciever than to make a "frankenface" that first converts to phone line standards, and then pay in the high 3 digits PER UNIT to get from phone line signals to the bag phone.

By cutting out the overpriced interface, I can vastly reduce the overall complexity of the system, plus have control over the low level functions, thus speeding up overall response time and simplifying the software.

The device I have looked at would make the project a "Rube Goldberg" contraption.

I want to locate a copy of that protocol, much like I can get the protocol for the PC/AT keyboard.

At the moment it may turn out more productive to just fork over about $900 for a logic analyzer and do my own reverse engineering of the handset protocol, as examination with an oscilloscope and breakout connector suggests it is a relatively simple inter-processor protocol for both keystrokes from handset to transciever and display from transciever to handset.

Then I can build maybe a dozen interfaces for the price of ONE of "brand X" phone line emulator to transciever interface, and not be at their mercy from a supply standpoint.

The down side is that if protocol changes are discovered in later phones, I've got to hook up the logic analyzer to the new phone and figure out what they changed, and modify the PIC include files as required to accomodate it.

The whole thing really started from a need to call a list of people from a remote site when something breaks, and keep calling until someone answers and acknowledges that they are on their way to fix it.

I need to build an interface (probably based on a PIC microcontroller) that will plug into a Motorola bag phone and pretend to be a handset being dialed.

While emergency auto-dialers are readily available for POTS (plain old telephone system), a simple cellphone interface just plain doesn't exist.

After many evenings with various search engines I did stumble on a magic box that makes a cellphone look like a phone jack, complete with 48 volt on-hook, ringing voltage, dial tone, DTMF, etc. However this thing has a price tag with too many digits to the left of the price tag, enough to pay for a really nice repeater site and a few extra goodies - for ONE unit!

I did find the pinouts and signal names for both the RJ-45 jack the handset plugs into, as well as identical signals available on the DB-25 at the end of the cellphone "brick".

There are 3 signals used to communicate between the handset and "brick": Data in, data out, and clock.

It is unknown if the data is on rising or falling edges of the clock, the maximum and minimum bit rates, any CRC or header information, or other protocol details.

Also I need to of course be able to assemble the proper bit streams to mimic button presses, and to parse bit streams from the brick to extract status information.

My guess is this is probably similar to IIC or SPI bus protocol, or even similar to reading / writing from a serial EEPROM, but I'd rather not spend months with a logic analyzer slowly picking apart the codes.

I did dig up in my research that handsets can be interchanged, but some of them support "extensions" to the basic command set, which are used for specific lines of phones.

So this implies that all of them share the core protocol, much as packetcluster and APRS use AX.25 frames, but the data output by a PIC-E hooked to a GPS will be different than a DX spot.

If I can get my hands on the basic protocol, I can then program a PIC to do the bit-banging.

I now have THREE (3) different Alinco DR-1200 radios whose LCD backlight is either nonfunctional or intermittent. Is there a tech tip / bulletin (or identified connection problem) related to this? I like to be able to see them at night without a flashlight. (severity: Nuisance)