Back to Scom Back to Tech Info Back to Home

Some thoughts and ideas on programming your repeater controller without a radio or a phone line... Compiled, HTML'd and maintained by Mike Morris WA6ILQ

Comments and additional material are welcome
(even "Hey - you've got a spelling error at..." messages)

Note: This writeup was developed from notes that the author took while programming Scom 5K, 6K and 7K controllers - but this technique works with any brand of controller that understands DTMF.   All references to the 7K in the text below apply equally well to the 5K and 6K (with the understanding that the 5K and 6K have fewer ports, different feature sets, different connectors, and different pinouts on those connectors - see this Scom pinout page).

Care was taken while generating this web page to make it "generic" - there is nothing in this writeup that precludes the ideas and principles displayed here from being used on any controller that expects to see it's programming come in via a radio port or an autopatch port... i.e. NHRC, Link (RLC), ACC, etc.   So those that don't have an Scom controller will still consider this article of value.   In other words, all references to Scom while automating the DTMF uploading apply to all controllers as long as the controller-specific details (such as connector pinout) and installation-specific details (such as active low or active high) are handled.

Note: If you decide to print this file to three-hole punch it and put in your controller manual's binder make sure that the schematic diagrams come out in a monospaced font (like Courier) if you want to see them properly.   I used an exclamation point as a vertical line since the actual vertical line character (upper-case backslash on many keyboards) is one of the first ones replaced by a local language character in non-USA keyboards and I wanted to make this file as international-compatible as possible.

The topic of directly connecting a computer to a controller (also known as local programming) seems to come up on the Scom mailing list (SCOM-Controllers at yahoogroups) between three and five times a year, so one night in July 2002 I created this web page that contains everything that I keep posting or emailing directly.   Now I can just point the new folks at it !

When the 5K, 6K and 7K series of Scom controllers were designed in the late 1970s and 1980s the fact that there was no serial port on the back of it was not seen as a shortcoming.   The home PC was not as common as it is today (the IBM PC wasn't introduced until late 1981), and besides embedded serial ports were expensive in hardware cost, in programming effort, and in firmware (program) space.   The microprocessor that runs the 7K is completely parallel I/O oriented - when it was designed there wasn't a member of the processor family with an on-chip serial port.   As a result, the 7K has no "inputs" except the touchtone decoder and the digital logic inputs, and no "outputs" except the tone generator (i.e. beeps, boops, and CW), the logic outputs, the optional display panel and the optional speech synthesizer (which is also a parallel device).   The only "path" for programming to get into the controller memory is through the touchtone decoder - either via a radio port or the autopatch port.   And it's actually easier to use one of the radio ports instead of the autopatch port! Why is that?   First of all, not every 7K has the autopatch board.   Second, the default programming has the controller ignore the autopatch port until it sees a ring signal (i.e. the phone line rings).   Third, it's not that hard to connect a source of automated DTMF dialing to a radio port, and lastly, just how many folks have two phone lines at home?

There is no practical way to add a serial port to the Scom 5K, 6K or 7K.   The design is essentially not expandable.   Yes, technically you could remove the CPU chip and install a daughter board containing the serial port hardware plus the original CPU, but that would buy you nothing.   The designer tells me that there is no room to add any firmware to handle a serial port without sacrificing existing functionality elsewhere.

In summary, from today's point of view one would think that the apparent Scom 7K design shortcoming makes programming more difficult that it needs to be.   The Scom Programmer software utility (that's an offsite link) does a lot to make up for that fact.   I heartily recommend that anybody with a 5K, 6K or 7K buy a copy - after reading the book, studying the sample files, and using it for a few days you will kick yourself for not getting it at the same time you bought the controller.

Basically you start with a virgin controller (i.e. open the case and hold down the internal reset button on the CPU board while you turn the power on) and upload the operating parameters through a PC running the Programmer software, and if later changes are needed you make them in the PC and upload again.   As long as you make all changes on the PC and upload them to the Scom the lack of a download feature is not critical (just remember to take good notes on all over-the-air DTMF programming and update the Programmer files).   The end result is that the Programmer Software removes the frustration of not being able to see what is in the controller - because on the Programmer screen and your Programmer printouts you have a precise record of everything in the 7Ks memory (because each and every byte of it went through the Programmer to get there).

If, on the other hand, you inherit a controller and have no idea as to the current programming then you will have a completely different can of worms...

If you have a Scom controller and you have to reverse engineer the programming you start with the book, and determine each of the controllers system wide settings, like the timeout timer duration, the IDer contents, the IDer morse code speed, the spacing, etc. To determine the contents of the macros you need to query each macro with one of these two commands:
(PW) 33 (MACRO #) will send out the contents of a macro is morse code to port 1, or
(PW) 35 (MACRO #) will spill out the contents of a macro in voice to port 1.

Either way, while you implement this methodology you probably want to have the controller on your bench with an amplified speaker connected to the transmit audio line.

There is NO direct way to force a warm start on an Scom, but you can use a known software bug as a feature with this trick (replace the 1234 below with a known-to-be-not-used macro number):
(PW) 20 1234 1234
Then call macro 1234.   The infinite loop will lock up the CPU, not update the watchdog timer, and the watchdog will force a warm start. Then delete macro 1234.

When I program one of several Scom controllers that I take care of either on the bench or at a radio site I use a laptop computer along with a old Hayes external modem (only because the PCMCIA modem card that came with the laptop has a design glitch - not all do - more on that later).   At the site I set up a $5 thrift-store card table (that I bought just for the site and keep at the site) and a folding chair, then I power up the laptop and connect the external modem.   While the laptop is booting I connect the controller with a common 4-conductor RJ-11 cord that plugs into an RJ-11 jack that I've permanently wired into the cabinet wiring on a receiver port (schematic diagram below).   I just make sure that I power off anything normally connected to the receiver port before I jack into it.   At the one site where there is no actual device hooked to the control RX port (yet!) the controller is still programmed to accept command codes on that port to allow local programming from the laptop.

Note that the data side of the modem is totally unused - the Scom Programmer software does all the controller programming just like you would do if you were pressing the DTMF pad keys on a handheld very quickly and without errors - like an Energizer bunny - it just dials and dials and dials... (note that setting the S11 register in the modem to a value of 50 to 60 will speed up the upload a lot).   Remember this: when programming a controller an old slow modem is NOT a disadvantage as the modem is used only as a serially controlled touchtone generator.   You can usually find the old Hayes or Practical Peripherals 300, 1200 or 2400 externals at the swap meets for $5 or less.   An alternate choice is a USR Sportster.   Make sure you get the proper wall wart / power pack with it - most of the Hayes or Practical Peripherals used a funny 3-pin connector, and different models used different DC voltages.

The existing Scom Programmer (ver 1.<anything>) is compatible with all Windows versions including Windows 3.11, and that compatibility limits the total size of the program and it's data to 64 KB of RAM.   This limitation affects both the total code size (the programmer itself) and the data size (i.e. the size of the programming file that is sent to the controller).   Upcoming versions will drop support for Windows 3.11 (i.e. require Windows XP or later) and that 64 KB restriction will be lifted.

Once I had the Scom Programmer software in hand I printed out the sample files that come with it and spent a few evenings taking apart and understanding exactly what the author was doing, line by line.   I then had a few emailed discussions with the author about a few topics that had come up and I started realizing that the lack of a serial port and not being able to download the code from the controller memory was not that big a deal.   From then on every change that went into my controllers memory went through the programmer software, so I had a copy of it on my desktop at home.   And before any hill trip I made sure that the files specific to that site were current on the laptop.

Hint: To get the most functionality from the Scom Programmer software you need to make heavy use of the named constants file (the NCF) - define everything you can in it (any constant value), and then break apart your programming into separate program files for:

1. The base programming - the timeout timers, IDers, etc. plus any "subroutine" macros like a function complete.
2. The macro definitions - the user commands, etc.   Try and have these call subroutine macros.
3. The autopatch programming - everything but the actual autodial / speed-dial codes / macros.
4. The autopatch speed dial numbers (yes, in a separate file.   This method allows changing one users autodial home phone number without reloading the entire controller).
5. The remote base programming
6. The named constants file itself

The operation of the Scom Programmer is such that the NCF is never loaded into the controller itself.   The Programmer examines each line as it is read from the data file and looks for Named Constants and replaces them with the constant's definition / value from the NCF, and does it on the fly, line by line.   By dividing the overall programming of the controller into logical sections (similar to what is listed above) you can keep each code file small.   You will find that usually you only have to modify one program file and maybe the NCF then reload the program file.   As I mentioned above I have all the autopatch autodial numbers in one file, and changing a number means that I only have to upload one file - not the whole controller.

Whe I first got the Scom Programmer software I created a single super-sized programming file for our primary system - a UHF repeater with autopatch, 2m remote base, NOAA weather receiver plus several features such as separate switched fans for the repeater RF amplifier and the remote base transmitter.   Before I got the hang of breaking apart the monster and using the NCF I was tempted to add a reset button and power switch to the front of the controller - I was having to reset and reload the unit frequently during the progam development / debugging phase.   Now when the programming of my controller seems to screw up, I just look at the screen (or a printout next to the controller manual) and play with the test bed controller and figure it out.   Then I fix the programming and overload the bad programming.   Only twice in 10 months or so of R&D have I had to do a cold start (i.e. wipe everything and reload from scratch) - one was a macro loop that I could have gotten out of (yes, there is a way to do it) but it was easier to cold start.   A full reload of the entire controller - all of my files - takes less than three minutes with S11 set to maximum speed (which you can only do on a direct RJ-11 cable connection).   And after our programming was finalized I haven't had to touch it (except for changing a few command macro names when we changed control ops) in several years.

For a local programming direct connection you can do one of two things:

1. Wire a DB-25 to RJ-11 adapter appropriately, perhaps with the COR / CTCSS decoderswitch mounted into the adapter shell (side wall or top cover).   More on this below.
   
   
2. Wire an RJ-11 jack in parallel with whatever you have attached to any of your controller's receiver ports (I use receiver #3), and remember to power off whatever is on that port before you start programming - you don't want somebody keying up on that frequency and confusing the upload process.
   
   
3. Wire a 3 pole (or 4 pole, more on that later) double throw (perhaps with a center off if you want) switch onto the receiver port (i.e. into the repeater cabinet wiring harness) and select either the normal device or the RJ-11 connector.   A center-off switch is not required but allows you to select a "receiver port offline" mode without powering off anything.

Note: (and this is important) All of the Scom installations that I work on use low-going (i.e. active low, ground when active, pick your term) COR, CTCSS decode and PTT signals. In the schematics below I show a switch that grounds the COR and CTCSS decode pins. If your system uses active high signals you will need to wire your switch to a source of + voltage through a 4.7k or 10k pull-up resistor rather than to ground.

The common "RJ-11" telephone line connector is implemented as 2, 4, or 6 pins in a a 6-pin connector body, with the most common implementation (a single line phone) using the center 2 pins.   The pins are numbered 1-6, with 1 and 6 (the outermost pins) used only with a 6-conductor implementation, and pins 3 and 4 as the center two pins that are normally the phone line. The wiring connected to those two pins are usually red and green, or white-with-blue-tracer and blue-with-white-tracer).   The common residential phone line in the USA is a balanced pair, both sides isolated from ground, and if you exchange the two wires it won't matter (unless you have a really old or weird device that is sensitive to the phone line polarity).

The circuit below can be wired into a DB-25 to RJ-11 adapter with the COR / CTCSS decoder switch mounted into the adapter shell (side wall or top cover).   The trimpot shown in the diagram below may not be needed... it depends on the audio level coming out of the modem, and the input audio level of your controller (i.e. how sensitive you set it).   A trimpot will fit inside most shells and once set can be ignored (or you can drill a hole so that a small screwdriver can be used to adjust it).   Or you can use a full size pot on your breadboard, then measure it and use a pair of fixed resistors in the final product.   Follow the book on setting the Scom audio trimpots for your repeater environment, then set the trimpot in the schematic below to match that level.   On one of the systems I helped set up the recevier #3 port wasn't being used, and in that case we left the port active in the programming and we set the Scom recevier #3 pot to match the audio level coming from the modem.

+-+ +---+ !1! ! ! 500 ohm or 1K trimpot (optional, see text) !2!-- black ! / !3!-- green -----------------+ \<--- To controller receiver audio in (pin number varies with !4!-- red --------+----------+ / which receiver port - see table below) !5!-- yellow ! ! ! !6! ! +---+---- To controller ground (pin 19) +-+ ! ! ! +------ Controller receiver CTCSS decode in (pin number varies) ! ! / ! (this wiring assumes an active low CTCSS decode input) ! ! / ! RJ-11 jack +---O O---+------ Controller receiver COR in (pin number varies) for cable to ! (assumes an active low COR input) modem's ! "line" jack ! (i.e. the modem ! audio output) ! ! =============== ! ========== Everything below this point is optional ========= ! ! --+ +------------------- Shield / shell / shank ! ! 1/8" stereo headphone jack +------------------- Ring contact ! ! ! (see text) ! +------------- Tip contact ! ! ! --+ ! ! ! +------------- To controller TX#1 audio out (Pin 14) ! +------------------- To controller transmitter #2 audio out (Pin 15) (transmitter #2 isn't really needed, but I didn't have a mono jack in the junkbox and this lets me use a set of common amplified PC speakers to monitor both transmit ports of the controller) +-------Red LED--------- To controller transmitter #1 PTT (pin 10) ! ! +----Red LED--------- To controller transmitter #2 PTT (pin 11) ! ! ! +---/\/\/\/\/-----+ The resistor value is dependent on if the LEDs are ! ! 2ma, 10ma or 20ma and is discussed in the text below ! ! +------/\/\/\/\/-----+--< Hot side of controller style +12vDC power input connector ! ! +------/\/\/\/\/-----+--> To hot side of power out cord (plugs into the ! +12vDC power jack on the back of the controller) ! +------Green LED--------- To controller GND

I mounted an 1/8 inch earphone jack into the side of the DB25 connector shell and connected the tip lead to the transmitter #1 audio.   The audio for transmitter #2 is monitored only because the junkbox had a stereo jack and adding an extra piece of wire to the second audio channel pin was easy.   This has proven both convenient and useful while developing the remote base programming.   A cheap PC-style amplified dual speaker set plugs into the headphone jack and lets me monitor both transmitter audio channels without requiring an operational repeater / remote base.

To extend the concept of monitoring the controller transmitter audio, I drilled the front panel of my spare controller that lives in my programming test-bed (i.e. the garage repeater) and mounted another 1/8 inch jack there as well.   I connected the left channel to TX#1 audio and the right chanel to TX#2 audio right from the back side of the DB25 in the controller.   A better way is to tap onto the high side of the level set pots through isolation resistors.

Add these two resistors and 10uf 25vDC an earphone jack +!! ---------+ <----------\/\/\/\/\/\---------+---!!---- To earphone jack tip or ring ! 4.7, 10k or 15k ! !! ! 1/10, 1/8 or 1/4 watt ! \ ! / / adjust this resistor \<-------- \ value for a comfortable / / level in your speakers... \ Transmitter level set pot \ between 4.7k and 22k, 1/8 or 1/4 w... / TX #1 = R104 in Scom 7K / or maybe just leave it out... \ TX #2 = R105 in Scom 7K \ depends on how sensitive the / (both are next to U35) / amplifier in your speakers is. ! ! ! +------ To earphone jack shank ! ! ! ! gnd gnd

Back to the test/programming adapter....Hanging from my DB25 shell are two pigtails - one with a male and one with a female power jack identical to that on the Scom 7K (I took a Radio Shack power extension cord and cut the connector ends off leaving about 4-6 inches of cable on each connector).   If I need to program a 7K that does not have one of my RJ-11s hard-wired into the cabinet wiring I just unplug the cable from J2, plug in my adapter, unplug the power cord going into the 7K and plug it into my adapter (to provide the +12 for the LEDs), and plug the pigtail into the 7K power jack.   As to the LEDs themselves, I used the smallest diameter 2ma LEDs I could find.   As to the LED resistors, the rule of thumb on the 2 ma LEDS is 500 ohms per volt, and I used 5.6 K 1/4 watt resistors.   The 2 ma LEDs are rare in surplus, you will probably find that 10ma LEDs are more common, and for them 100 ohms per volt is the rule, which works out to 1.2 K on 12 to 13 volts DC. The higher current 20 ma LEDs require 620 or 680 ohm resistors.

The diagram below shows how you can make the programming jack permanent in your repeater rack or cabinet.   The RJ jack and a 3PDT changeover switch can be grafted into the repeater cabinet system wiring.   If you mount a RJ-11 baseboard jack into your system cabinet, well, I've seen a baseboard mount RJ-11 whose housings are large enough to mount the switch (and any trimpots if needed) into...   Mine are cabled into receiver #3's wiring so I can make a programming change via receiver #3, then depending on which part of the controllers behavior I've just changed I can use a handheld on the main repeater channel (recevier #1) or the remote base (recevier #2) channel to test the change immediately.

RJ-11 jack for cable to modem "line" jack (i.e. the modem audio output) ! ! ! +-- To your RXn audio output (what would normally ! ! connect to the 7K RX audio in...) +-+ ! !1! +--O !2!-- yellow > <----O--to 7K RXn audio in !3!-- green ----------(**)-O !4!-- red ----------+ !5!-- black ! !6! ! +-- To your RXn COR output (what would normally +-+ ! ! connect to the 7K COR in...) ! ! ! +----O ! > <----O--to 7K COR in (assumes active low) +-------O ! ! +-- To your RXn PL decoder output ! ! ! +---O ! > <----O--to 7K PL decode in (assumes active low) ! +---O ! ! +---+----------------- 7K ground

Scom 7K J2 (female DB-25 connector) Pinout Function Receiver #1 Receiver #2 Receiver #3 Audio In 1 8 25 COR 2 3 4 CTCSS decode 5 6 7 Common Ground 19, 20, 21, 22

- - - optional - - - - - - requires a fourth pole on the switch that provides a tattle-tale - - - - - - to remind you to flip it back to normal before you leave the site - - - bright normal or 1.2 K (if 10ma LED) self-blinking or 560 ohms (20ma LED) O red 10 or 20 ma resistor > <----O-------LED------------------/\/\/\/\----- +12v +---O ! +------------------------------------------------- 7K ground

The (**) in the diagram above is where you would insert the 500 ohm or 1K ohm trimpot shown in the first schematic, if it's needed.

There are two different color codes in use on modern telephone jacks.   The red-green-yellow-black colors listed above are thr older color code.   If your RJ-11 jack has the newer color code then the green wire will be a white wire with a blue tracer and the red wire will be a blue wire with a white tracer.   The black and yellow pair will be a white wire with an orange tracer and an orange wire with a white tracer.   If it's there the third pair will be blue and white and the newer jack will have a white-green and green-white pair.

The above diagram is drawn so that when the three-pole (or four pole) double-throw changeover switch is in the up position the system is normal, the center position has the controller radio port idled, and the down position switches the 7K audio input to the modem and simulates both COR and PL decode active.   Naturally when you mount the switch, you would want to mount it upside down from the drawing so that "down" is repeater normal.   If your junkbox yields a switch with a fourth pole, you can use it to light an annoying red LED mounted next to the switch signfying "not normal" or "programming mode".   One of my friends junkbox had a LED with a built-in flasher/blinker so his installation has a blinking tattle-tale LED...

Automatic COR and PL Decode signal control:
Some of the external modems had an extra pole of the off-hook relay connected to pins 2 and 5 of the RJ-11 connector (enabled by the ATJ1 command).   This relay function was used to support the older multiline phone systems of the day that shorted those two pins to mark the phone line as off hook (these were the "1A2" 5, 9 and 19 line phones with the fat cables that had the 50-pin / 25-pair Amphenol connectors).   If you can locate an older external modem - one that has this relay (the Hayes 1200 and 2400 were two) - then you can use the full diagram below as your wiring.   When the modem goes offhook the controller automatically sees both COR and PL.

If you feel like it you could also open up any old modem and add an additional reed relay into it - just wire the coil of the new relay in parallel with the coil of the existing relay, and the contacts across the extra RJ pins.   Or if you get lucky, you might find a spare set of contacts on the existing relay - I have.   I've also found a two-pole relay with one pole in series with each side of the phone line.   They can be rewired with a couple of etch cuts and jumpers so that one pole is on the phone line and the second pole is on the RJ-11 pins 2 and 5.

RJ-11 jack for cable to modem "line" jack (i.e. the modem audio output) ! +-- To your receiver COR output ! ! +-+ +---O !1! > <----O--to controller COR input !2!--- yellow ---------------------+---------O (assumes active low) !3!--- green -------------------+ ! !4!--- red ------------------+ ! ! !5!--- black --------------+ ! ! ! +-- To your receiver CTCSS decoder output !6! ! ! ! ! ! +-+ ! ! ! ! +---O Black and yellow ! ! ! ! > <----O--to controller CTCSS decode input are shorted by ! ! ! +---------O (assumes active low) relay contacts ! ! ! inside the modem ! ! ! ! ! ! +-- To your recevier audio output ! ! ! ! ! ! ! +---O ! ! ! > <----O--to controller RX audio input ! ! +---(**) ----O ! ! +-+----------------------- to controller ground And of course should you have a four-pole switch you can wire the fourth switch pole and a tattle-tale LED as per the diagram above.

The (**) in the diagram above is where you would insert the 1K trimpot shown in the first schematic, if it's needed.

As in the previous diagram, the drawing above has the changeover switch in the up position as normal, the center position has the 7K port idle, and the down position allows both COR and PL decode to look active when the modem goes offhook.   Center-off is optional, I used center-off switches because I had them in the junk box, and I'm glad I did: it gives me an easy way to disable the controller port.   When you build it you will want the down position of the switch as normal and up as the modem mode.

Over the air:
You can also program over the air with the modem operating as a touchtone generator... just be careful as to who hears you.   We have our control channel in spectrum that most folks can't monitor (and that's all I'm going to say about that).   Instead of cabling the modem audio to a receiver port on the controller, just cable the center two pins of the RJ-11 to the transmitter audio input (through an audio transformer if you need isolation and through a pot for audio level control if you need it).   You can use a toggle switch for PTT... or...

Automatic PTT: You can also use the extra relay in the early Hayes to handle PTT if you want by connecting the the yellow and black wires of the RJ-11 jack to the PTT function.   Or as I mentioned above, add an extra relay inside the modem case.   It's worth doing as the programmer will automatically drop PTT at the end of transmitting the file - you can start a programming session and go get a cuppa soup or coffee knowing that your transmitter won't have a meltdown if you don't get back in time.

Automatic ID: One handy feature that the old Hayes 1200 external has that nothing else ever had or has now... it can ID your transmitter in true MCW automatically.   They dropped that feature in the later Hayes 2400 model.   I first heard about that feature in the non-fiction book "The Cuckoo's Egg", written by Clifford Stoll K7TA - it's quite a tale and really worth finding in a used bookstore.   There was also a "Nova" PBS-TV episode about it - if you see it scheduled it's worth setting your VCR or TiVo or MythTV to tape it, if for nothing else than the shots of manually tracing a phone call through the old Siemens step-by-step central office with the glass-encased Strowger switches (mechanical two dimension stepper switches).   But, back on topic, you will have to find a Hayes 1200 book to look up the ATDM codes to send the MCW.   Then in the Scom programmer put a string defining your callsign in the "init" and "exit" sections of the modem codes and your programming session can ID at the beginning and the end.   Don't worry about any string length limitations on the "init" and "exit" strings - they are stored in the .INI file and the Programmer author assures me that they have no real maximum length - they are limited only by the size of your hard disk.   If anyone would like to contribute a scan of the Hayes 1200 information I'll be happy to add that information to this page.

Comments on modems:

You will want to verify that the Smartmodem modem you are using will send the A, B, C and D touchtone sequences (the fourth column on the DTMF pad).   I have used Hayes and Practical Peripherals brands and know that they work - but there are some modems that ignore the A, B, C, and D (skip over them in the sequence), and Ive been told that some of the cheaper modems just freeze.   You need a modem that treats one of those characters as another dialing digit.   If anyone would like to contribute information on others that are known to work (or that are known to not work), I'll be happy to add that information to this paragraph.

The Hayes and Practical Peripherals 300 baud, 1200 baud and 2400 baud modems that I have used are old enough that the electrolytics have probably dried out.   If you pick up one that has not been powered up in a while it would be worth opening the case and doing a pysical inspection of every electrolytic.   Look for bulged or leaky cases.   If they all look OK, then plug the wall wart power pack into a Variac and ramp the AC voltage up from zero to the line voltage at a rate of 10-20 volts per hour.   You may still have to replace a bunch of old filter caps inside the modem.   At least these are old enough that the caps are not surface mount.

You will want to check the S6 setting in your modem - it's the one that controls how long the modem waits for dial tone before it gives up and blindly dials.   If it's set too long you could have a situation where the modem is waiting forever for dial tone before sending touchtone.   As far as I know there is no standard default setting for S6.   You may need to reset S6 and then do a AT&W to write the setting into the modem.   Or do an AT&F and an AT&W when you first get the modem to set it back to factory defaults.

I've not seen a modem yet that absolutely has to have dial tone before it will send touchtone - that just plain violates the smartmodem specification (which is an official EIA standard!).   But that doesn't mean that a offbrand modem design might not be out there.

I thought at first I had that situation when I was handed a Compaq 266 MHz laptop with a Megahertz brand PCMCIA card modem at a previous job (3Com later bought Megahertz).   (Am I dating myself? A P2-266 was current technology then)   It turned out later on that particular modem design simply uses the phone line voltage to power the analog side of the modem, and just wouldn't work unless there was DC voltage there.   It makes perfect sense in the normal world, and allows a modem design that uses less power from the laptop battery... it just won't work in the Scom universe, so when using that laptop I was forced to use an external modem to program a controller.   And don't assume that only the Megahertz, 3Com or PCMCIA modems do that power saving trick, the same chipsets are used in a wide variety of internal and external modems.

An easy way to test if your modem needs an external voltage source is to simply take an RJ-11 cord, and hook a PC amplified speaker to the red and green wires.   Start up your modem program and type ATDT1234567890ABCD and then press the enter key.   The modem should take the phone off hook and dial sixteen digits and they should be be audible in the PC speaker.

If you really have to use that type of a modem you will have to fake the DC voltage to it.   All it takes is a hum-free DC voltage source, a resistor and a capacitor.

Build the circuit below.   To test, plug a regular touchtone telephone (an ITT, GTE or Western Electric from the 80s or 90s - one that has a transistor-and-toroidal-coil-based touchtone dial) to the left side jack in the diagram.   Listen if you hear touchtone in the earpiece of the phone when you press a button on the dial (some really old dials were polarity sensitive - if you get just a click try swapping the two wires to the phone).   A 9 volt battery is convenient for testing the circuit, but may only last short time of serious controller programming.   A 10v to 15vDC wall wart (50 ma or more) with an extra filter capacitor or two across it's output may be more appropriate on a long term basis.   The goal is sufficient DC voltage to push about 15-20ma through the phone / modem without audio distortion.   Caution - most phones and modems will go into audio distortion if you push more than 30 ma down the line!

In short if an old ITT or GTE or Western Electric phone (something with a toroid-based touchtone pad) plugged into the modem jack works, then any PCMCIA or desktop modem should work.

RJ-11 jack for cable to modem "line" jack ! +-+ !1! 10 to 50uf !2!-- yellow ! ! !3!-- green ------+-------! !------------ 7K RX audio in !4!-- red ---+ ! + ! ! - !5!-- black ! ! !6! ! \ +-+ ! / 470 ohm to 1K - adjust ! \ the value for 15-20maDC ! / (no more than 30!) ! \ through the phone ! / or modem ! \ ! ! + - ! +----- battery ---+ ! or ! ! DC supply ! ! ! +----+-----------------+--- ground ! ! ! +---- 7K receiver COR in ! / ! (assumes active low) ! / ! +----------O O--+---- 7K receiver CTCSS decode in (assumes active low)

The coupling capacitor may not be necessary if there is one inside your controller (the Scom has it).   Don't use a tantalum cap in an audio coupling circuit.   They are great as a filter cap but when used as a coupling cap can do funny things to the audio (the capacitance can change with the voltage across the cap).

In place of the resistor you can also use a inductor - even a random transformer with a 600 ohm to 2K ohm winding.

A better circuit uses a transformer designed such that it doesn't saturate with DC current - this type of transformer can be hard to find which is why I had to come up with the above circuit - I had to program a controller with my work laptop at a friend's house on zero notice - so I dug through his junk box and found a resistor, a coupling cap and a battery clip.   My Fluke DVM temporarily donated the 9v battery.

The transformer in the circuit below can be either a dual 150 ohm primary winding and a single 600 ohm secondary, or a dual 150 ohm to dual 150 ohm (with the secondaries wired in series).   I've used three different types - the first was scavenged from an old Moto DC wireline control card from a MICOR base station line card, the second one came from from an old T-1200 series DC wireline control console and the third came from a old tube-type base station DC wireline chassis.

RJ-11 jack for cable to modem "line" jack ! +-+ !1! !2!-- yellow !3!-- green --------------------+ +------------- Connect this lead to the 7K audio input. !4!-- red ---+ ! ! !5!-- black ! ) !! ( !6! ! ) !! ( +-+ ! ) !! ( ) !! ( ! ) !! ( ! 560 ohms ) !! ( ! to 1.2k ! !! ! ! +--/\/\/\/\/---+ !! +----+ ! ! !! ! ! ! !! ! ! ! !! ! ! ! + - !! ! ! +-- 9 to 12v --+ !! +----+-------- If the RX audio level is too high when ! battery or ! !! ! using the top of the transformer then ! a well ) !! ( abandon the top connection and connect ! filtered wall ) !! ( this lead to the 7K audio input. ! wart DC power ) !! ( ! source ) !! ( If it's still too high then you will ! ) !! ( need to use the 500 ohm or 1K trimpot ! ) ( as shown in the first schematic. ! ! ! +------------------+ +------------- To 7K gnd ! ! / ! / +--O O--+---- To 7K receiver COR in ! (assumes active low) ! +---- To 7K RX CTCSS decode in (assumes active low)

Adjust the resistor and the DC voltage to push about 15-20ma (not more than 30!) through the transformer winding and the phone / modem without audio distortion.   Smaller core transformers will start to distort at higher current settings.   If you have excessive audio level use the alternate audio output as marked on the schematic above, or add the 500 ohm or 1K trimpot.

If your modem has the extra relay contacts mentioned above you can replace the switch with wiring to the yellow and black leads on the RJ-11.

Comments on the Scom Programmer...
First, if you don't have it, and you own a Scom controller or are involved with maintaining one, get it.   See the sales pitch web page at http://www.scomcontrollers.com/scompgmr/scompgmr.html for the details.   The current version as of this writing is 1.2.3 and if you have anything older it's really worth updating - and the update price is right at only US$15 dollars as of this writing (2003).

The Scom Programmer software has a "Site" and a "Modem" selection on the "Settings" menu.   There are separate custom initialization strings that can be sent to a Dialup Modem and a Direct Modem... they are there for a reason - in my case I have the Direct Modem setting send S11=60 to speed up the programming but you could use it to set S6 as well...   You could also have a "Site 1 local" entry, a "Site 1 dialup" entry, and a "Site 1 RF" entry, with different settings for each.

Some starting settings are:

• Add M2L3 in Init #1 to turn the speaker on and then adjust the L number from 1-3 to set the volume to your comfort.   Some cheaper modems only allow zero (Off) and one (On) in the M and L commands.
• On a direct connection (a wire) add S6=0 in Init #2 (to bypass the "wait for dial tone" function.
• On a direct connection (a wire) add S11=50 in Init #2 to speed up the DTMF as fast as the 7K will take it.   On the S11 setting the lower numbers result in shorter DTMF pulses and therefore faster dialing.
• On a modem connection (a dialup to the 7K autopatch port) start with S11=70 in Init #2 to speed up the DTMF as fast as the 7K will take it.   Shorten the pulses (lower the value) until the link starts to error, then lengthen it 10% to 15%.
• On a radio link set S11 to a slower number - maybe 95 or so.   Shorten it until the radio link starts to error, then lengthen it 10% to 15%.
• Use the Exit setting to put the DTMF speed back to the speed your local phone company likes.   My desktop USR Courier modem factory defaults to a value of 70, my local Pacific Bell central office starts to misdial at 49 or 50, I use 55 at home, your milage may vary.   If you have DSL then you aren't using a modem, ignore this.
• Start with Max Dial String Length (the number of digits the Programmer can send to the modem at a time) set to 32.   When I get a new modem I just keep raising it until it fails/errors/drops digits, then back off to the max the modem can take.
• If you have call waiting make sure you set the *70, (or 1170,) as part of the landline dialing string. Naturally that doesn't matter when you use a direct connection of the modem to the 7K.

It's a good idea to program all init string commands in the Scom dialer using all upper case alphabetics as some old offbrand modems didn't understand lower case (no, I'm not kidding).   As easy as it is to hit the CAPS LOCK key and type all upper case the one time you set up the strings, why ask for future problems?

Programming suggestions:

If you are programming over the air make sure you have a full quieting (preferrably fully capturing) signal to the repeater with no multipath distortion. If you have a local idiot in your area then do any remote programming through the dialup autopatch port with the autopatch audio muted and the DTMF priority set so as to ignore the repeater receiver during the programming. Or just do the programming locally - i.e. from in front of the repeater.

If you are programming over the air make sure your radio doesn't melt down. Some programming sessions might have 30 minute long transmit periods. You might need a radio that can handle a long duty cycles, or a beam antenna and a lower power / cooler running radio.

• I shouldn't have to say this, but don't use the default passwords. The Scom controllers have Master Passwords (MPW), Control Op passwords (CPW), Autopatch Passwords (APW), etc. Use them! Program the controller with a non-default MPW, but have the PWs inside the macros be the CPW. Make sure the change password command only works with the MPW. Have "Lock" and "Unlock" macros that change the CPW. "Lock" changes it to something that is only used in the Unlock macro, and Unlock changes it to what is used in the macros.
• Make sure the pacing of the DTMF is not going to overrrun the controller. Use the S6 parameter in the modem to tweak that.
• If you normally have DTMF mute off in your repeater then turn it on during programming.
• The 7K has a prioritized DTMF decoder. At the beginning of the file set the priority to the exclusive use by th eport you are using to do the programming. At the ned of the file put it back to normal configuration.
• Set the timeout timer to infinity. This prevents a timeout during the upload. Set it to the normal value just before the end of the programming.
• If you are doing a full reload then make sure that you use the erase all macros command very early in the programming as the macros won't overwrite.
• Have an audio progress message in the file. Just have a command that says "One" about 5% into the file. "Two" is at 10%. "Three" is at 15%", etcetera. "Twenty" is right around the end point.
• If appropriate put IDer strings in with the audio progress messages.
• Set the two error message to a voice string - "Error One" and "Error Two" instead of a morse message. That plus the numeric progress messages will help find any bugs.
• Set the OK message to a single or a double boop.   I use 35 ms of 900 Hz followed by 35 ms of silence followed by a second 35 ms of 900 Hz - this fast double beep speeds up the uploading.
• At the end of the programming file have a section that sets the timeout value, the DTMF priority, etc. all to their normal values. Have the last one be the OK message as the change from the periodic fast boop-boop to the courtesy beep that is used on the air so that you know that the upload is done...

Finally...
Good luck and after you get it working please drop me an email and let me know how things went.   I've spent a lot of time on this web page, and sometimes I'm wondering if anybody reads these missives to the masses...

Contact Information:

The author can be contacted at: his-callsign // at // repeater-builder // dot // com.

Back to the top of the page
Back to the Scom index
Back to the Tech Info index
Back to Home

This web page created July 2003

If you see something above that is vague, missing (or outright wrong), please let me know!   It's input from the readers that make these writeups better - I've probably either totally missed or shortchanged topics and/or subtopics that really need to be covered.

Text and hand-coded HTML copyright © Michael R. Morris 2002 and the date of last modification

This web page, this web site, the information presented in and on its pages and in these modifications and conversions is © Copyrighted 1995 and (date of last update) by Kevin Custer W3KKC and multiple originating authors. All Rights Reserved, including that of paper and web publication elsewhere.