Notes from Dave's Workbench (during 7330 development)

(Updated 5/28/2006)

There's a whole lot of testing going on!

Dave: Quite a bit of time has passed since the last update from the workbench. But, it's not from lack of activity! It's sometimes difficult to tear ourselves away from all the fun of development.

Since our last update, I've finished a complete set of diagnostics to wring out every last corner of the design. The diagnostics let us perform every function that the Repeater software makes use of and is a tool Bob will use to verify each newly assembled controller. I've also ported the 7K Message Handler to work with the new tone generators and speech hardware. It's interesting to listen to three different speech messages come out of three speakers all at the same time.

As you can see in the photo, I have a full test harness connected to the controller to exercise all the audio and logic inputs and verify the operation of all the audio and logic outputs. The connectors and switches across the back of the board, left to right, are serial port #1, serial port #2, logic in/out/a-to-d, the reset and init switches, a new locking power connector, and the three radio ports. The logic analyzer probes in the picture are attached to the flash PROMs that we're using to store the software, configuration, and speech files.

Do you recognize the front panel board? It's from a 7K. I used it for testing while the 7330 front panel was under development. We'll have front panel boards shortly so we can update the diagnostics and finalize the interface software.

The Repeater software is coming along nicely. Steve has built an automated test harness for fully automated testing of repeater software functionality and has been testing Bob's port of the Repeater software and continuing the port. There's only a few pieces left to finish. Steve has also integrated a really nice Windows-based debugger so that we can quickly single-step through code, identify any problems, repair them and move on.

Virgil has another prototype on his workbench and has been running the power supply and analog circuitry through its paces. Scott and I have been working through some issues that Virgil identified and adjusted the diagnostics to allow Virgil to get a really good look at the tone generation.

And, of course, Bob is busy preparing for the production run and finishing up the cabinet. His wife-to-be is happy to hear that he's taking a break from development to attend his own wedding ;-)

Be sure to take a look at the 7330 web page and read Bob's white paper, 7330 New Directions!

Ok, back to the workbench...

It's not your father's 7K

Bob writes: "The new controller brings controller technology into the 21st century. I'm taking the 7K code and expanding it to serve multiple independent ports.

"Since the multiple ports have totally independent hardware -- DTMF decoders, speech generators, tone generators, etc. -- there will be multiple 'instances'of the message handler software, the DTMF decoder software, the COR/PTT software, and all the rest. I frequently consult with the the two Daves to make sure the human interface (the appearance and syntax of the commands) stays true to our traditional style."

DaveM writes: "Because of all the new resources that must be configured and controlled, some of the commands are being enhanced, some are gone, and there are some new ones. There are many more Event-Triggered Macros, Messages, Timers, Paths and Macros. You'll recognize the commands, but there will be another digit to specify the additional resources. To make this all easier to manage, the new S-COM Programmer II will help by providing property pages and wizards to guide you through the configuration process."

What's the new controller naming scheme? Will there be an 8K?

There will definitely be a next-gen model (actually, a series of models), but we're leaving the old "K" nomenclature behind.

Here's how the new naming scheme will work.

The next-gen controllers will borrow heavily from the 7K's command set and basics of operation. After all, the 7K was the last controller in a series that began in the early 70's with wirewrapped boards, so it benefitted from literally man-years of improvements. It'd be silly to throw all of that away and start over.

Since the next-gen controllers will be based on the successful 7K architecture, we're using a leading "7" in the model number. Since these will be true multiport controllers, we want to show the number of ports in the model number. So, the 2nd digit will be the number of receivers supported, and the 3rd digit will be the number of transmitters supported.

The last digit will reflect major model changes.

So, the first controller to come out -- a full 3-port -- will be the model 7330.

Why are you starting with a 3-port controller?

Frankly, I had originally wanted to build a 1- or 1.5-port controller (like the 5K) to test the new hardware. But then we decided to build a replacement for the 7K, which meant a 2.5-port controller (three receivers, two transmitters). Those are the prototype boards we now have.

Over the years, customers had requested that we figure out a way to add a 3rd transmitter to the 7K, even at the expense of deleting the autopatch. And, since there's been some recent introductions of larger competitive controllers, we've decided to modify the design and add the third transmitter.

Our new design is scalable, so it won't take a lot of time and resources to build controllers larger than 3 ports. The size and type of controllers after the 7330 will be determined by the market. The members of this list will play a key part in determining what the new controllers will look like!

Let's talk about the power supply

Bob writes: "Let's talk about the power supply. Pretty basic, right? Just slap in a couple of linear voltage regulators and let 'er rip.

"Well, we didn't want to do it that way. The new controller will draw more current than previous models, and with linear regulators, more current means more power dissipation and larger heat sinks. And then there is the issue of the input voltage range.

"We're all pretty much used to having +13.8V available to run the repeater and its controller. That's a fairly high voltage when the logic needs +5V and less, and with a linear regulator, the difference is turned into heat. Also, there have been some requirements over the years for the 7K to run on +10V or less. That can't be done with the existing design because the 7K's first regulator needs 2 to 2.5V of headroom above its output, which is +10V. (That +10V is used for the audio circuits and is also regulated down to +5V for the logic. At least the total dissipation is divided between two heatsunk regulators.) And should I mention that on a few occasions, controllers are supposed to operate on +20V to +25V when the main power supply's pass transistors fail...? :-)

"Virgil, W0INK, designed a power supply for the new controller that combines switching and linear regulators.

"First, a switching regulator drops the incoming voltage to +5V. It's very efficient and has a very wide input voltage range (+9 to +36VDC!). There's a series input diode for reverse polarity protection, and power connections will be made via a Phoenix detachable screw terminal block (no more 2.5mm jack).

"Second, the +5V regulator feeds a +3.3V, 2.5V, and 1.2V linear regulator.

"There you have it, a robust, four-voltage regulated supply that has a very wide input voltage acceptance range. But in order to get there, we had to evaluate a number of competing parts and build up some prototype supplies to prove the robustness of the design."

 

What will the front panel look like?

Bob writes: "The display will look something like the 7K's. It'll have blue 3mm LEDs to show the states of the logic inputs, logic outputs, CORs, PTTs, and so on. (We're avoiding red LEDs because many people associate red with an indication of danger or warning.)"

 

 

What will the new controller cost?

Bob writes: "The exact cost is undetermined at the moment, but the goal has always been to price it close to the 7K on a price-per-port basis. Keep in mind that, unlike the 7K, there is no need for an optional speech synthesis module or DADMs in the new controller. Those functions will be standard."

Will the new controller have serial (RS-232) ports?

Definitely. Two serial ports provide access to the controller for programming and connection of other devices.

What is the connector pinout for interfacing the radios?

Each port has a DB-9 female with the following pinout:

Pin 1	Rx Audio Input
Pin 2	Rx COR logic Input
Pin 3	Rx CTCSS Logic Input
Pin 4	Tx PTT Logic Output
Pin 5	Tx Audio Output
Pin 6	Ground
Pin 7	Ground
Pin 8	Tx CTCSS Audio Output, or Logic Output
Pin 9	Ground

(This pinout surrounds the RX and TX audio pins with low impedance signals to get good isolation.)

And yes, I've now let the cat out of the bag regarding pin 8! The 7330 has three CTCSS encoders, one for each transmitter. Each has a level pot and outputs a very well filtered sine wave -- along with 180-degree reverse burst! The internal encoder can be controlled like the 7K's CTCSS CTCSS audio switch so that it can "follow" the COR, etc.

A jumper selection in the controller allows the pin 8 output to be a logic output that can be used for rig control, for example, for disabling an external CTCSS encoder to implement "chicken-burst".

Pin 3, RX CTCSS, is a logic input and is intended to receive the output of an external CTCSS decoder. In other words, it works just like the 7K's CTCSS inputs.

Why not use the same DB9 pinout as ARCOM and Link Comm?

We're open to ideas, but in this case I like our pinout better.

The other scheme has TX audio on 4 and RX audio on 5, which are adjacent pins in a DB-9.

Ours has RX audio on 1 and TX audio on 5, which are as far apart as you can get in a DB-9. The pins adjacent to RX audio are COR and ground, and the pins adjacent to TX audio are PTT and ground, so only DC signals are near the audio pins.

The TX CTCSS tone output (another "audio" pin) is near the center of the DB-9 and is surrounded by PTT and RX CTCSS, both DC signals.

It's really important to isolate RX and TX audio. Long-time listmembers will recall that we've solved complaints about partial DTMF muting and other audio feedthrough problems by having the customer replace a multiple-conductor shielded cable with individually-shielded cables.

What is the connector pinout for the I/O connector?

I've been asked to provide the pinout of the I/O connector, so it appears below. The connector is a DB-25F, and it handles the eight logic outputs, the four logic inputs, and the three A/D inputs.

And speaking of logic outputs, we've improved that area in the new 7330 controller. Recall that we've been using discrete power MOSFETs to drive the logic outputs and PTT lines in all of our products starting with the MRC-100 controller over 20 years ago. Since those devices are occasionally blown up by wiring crossovers and other hookup mistakes, we switched to socketed DIP IC drivers in the 7330. Each IC contains eight power MOSFETs and is similar to the ICs used to drive the 7K front panel LEDs. So, if a logic output or PTT line is blown on a 7330, the problem can be fixed by replacing a socketed device rather than a soldered-in device.

Here's the I/O connector pinout:

Pin 1	Logic Output 1
Pin 2	Logic Output 2
Pin 3	Logic Output 3
Pin 4	Logic Output 4
Pin 5	Logic Output 5
Pin 6	Logic Output 6
Pin 7	Analog Input 3
Pin 8	Analog Input 2
Pin 9	Analog Input 1
Pin 10	Logic Input 1
Pin 11	Logic Input 2
Pin 12	Logic Input 3
Pin 13	Logic Input 4
Pin 14	Logic Output 7
Pin 15	Logic Output 8
Pins 16-25	Ground

What support does the 7330 have for remote base control?

The 7330 continues to support the RBI-1.

The 7330 has a second RS-232 port for controlling external devices at the site. It could be for rig control, weather station control, or other things, but it takes time to write the appropriate software.

Will the new controller have audio capacity similar to the 7K with a Vyex DAB installed?

First of all, there's no need for a separate speech board; the digital audio player function is a built-in, no-added-cost feature of the 7330. Let me explain why this is such a significant breakthrough.

I like to call the 7330 a "true" three-port controller. With a true multiport controller (in my opinion), each repeater thinks it has its own controller. There's no sharing of any resources. When you look at other controllers, you'll always find sharing taking place at some level -- maybe the DTMF decoder is shared, or the tone generator is shared, or the speech synthesizer/voice playback is shared, etc.

That means one repeater has to wait while another uses the resource. Even today's most expensive controllers cannot identify two or more repeaters in speech, simultaneously, with different messages. That's because they have only one piece of hardware to generate speech for the whole controller.

The 7330 has three digital audio players, one for each port. Each of the three repeaters can voice identify itself, simultaneously, each with a different message.

(To go one step further, consider this: Having one 7330 is actually better than having three one-port controllers, because you can command any part of the whole system via any port. If you had three separate controllers, how would you command the number two repeater if you only had access to the number one repeater?)

Regarding digital audio storage, we went with ICs this time. We'll evaluate memory cards again when we do a bigger controller, but right now, we're trying to build the best value three-port controller.

The amount of storage available for customer speech is approximately 7MB.

How does the Audio Gating work?

A good reason to give each port its own full set of resources is that the audio gating requirements become quite simple. Here's why.

The 6K, 7K, and some other controllers use an IC called a crosspoint switch to connect the various audio sources and audio loads together under microprocessor control. The 7K's crosspoint switch has twelve inputs and eight outputs. It can connect any of its three receivers to the two transmitters and to the DTMF decoder; it can connect the CW generator to either or both transmitters; and so on.

If each receiver has its own DTMF decoder, then a portion of the crosspoint switch is no longer needed. Likewise, if each transmitter has its own CW generator, then another portion of the crosspoint goes away. We can further chip away at the crosspoint requirements by dedicating separate DTMF encoders, paging tone generators, and speech synthesizers to each transmitter.

What remains is receiver-to-transmitter gating, which can easily be done by simpler and cheaper parts than a crosspoint switch.

In fact, the 7330 controller uses just three triple-SPDT switches to do the whole job. Each receiver feeds three switches, which in turn feed the three transmitter audio mixers. The other resources (DTMF decoders, CW generators, paging tone generators, etc.) are hardwired to their respective ports with no gating required.

Thus, we not only gain flexibility with individual resources for each port, but we also save money on gating circuitry.

How do I set the audio levels? Are they remotely controllable?

You're probably familiar with digital pots; they're ICs that mimic mechanical potentiometers, but with the added benefit of being remotely controlled via logic signals.

It seems like repeater controllers could make good use of digital pots, so that'll be the topic of this note.

Long ago, controllers used mechanical pots not only for controlling audio levels but also for setting tone frequencies, timers, and so on. Fortunately, we now have much better ways of doing most of those things, but I still like mechanical pots for certain level control applications.

Take RX and TX levels, for example. It might seem like a digital pot would be a good choice for this application, but they do have some drawbacks.

1. Digital pots aren't exactly like mechanical pots in that they are ICs with power and ground pins. The signal being controlled by the pot can't exceed the pot's power supply rails or else the signal will be clipped. While a few digital pots can run from 15V supplies, most run from 5V supplies -- and the model 7330 uses 5V for its audio supply. We didn't want a higher voltage supply just to accomodate the digital pots, so that means a customer couldn't feed a receiver audio signal exceeding 5V p-p into the controller, even if the pot was used to attenuate the signal.

2. A controller's RX and TX pots need to be set properly when getting it up and running at a site. If those pots are digital, then a laptop would probably be required to do the installation because the DTMF decoders won't work if the audio level isn't right -- and you can't change the pot settings without somehow entering commands.

3. I view settings like RX and TX levels as 'calibrations' because they need to be done initially at installation time and seldom afterwards.

For the above reasons, plus the facts that mechanical pots have a nearly infinite resolution vs. 100 or 256 steps in a digital pot and are far less expensive, we opted to use mechanical pots in the 7330 for setting the RX and TX audio levels, the CTCSS encode levels, and the durations of the audio delays. Therefore, there are twelve pots in the 7330.

On the other hand, there is an area that can really use digital pots: Tone generators and digital audio players!

It seems like CW and beep levels are never quite correct, right? Well, how about being able to program the tone level in 256 steps for all CW characters, beeps, tone pages, and digital audio? With that ability, you can program different levels for different messages, or even change the level between CW characters and/or beeps. Talk about ways of getting your users' attention! And you won't have to make trips to the site just because a CW ID is too loud or a courtesy beep is too soft.

Actually, using digital pots in the tone and digital audio circuitry was an easy decision to make. Recall that the 7K has one pot for CW/beep level, another for paging tone level, another for DTMF generator level, another for speech synthesizer level, plus it has audio gating to select between the CW and tone page pots. A three-port controller would need three times that amount of circuitry -- and it still wouldn't allow for remote adjustment. Plus, you'd have to be sure to set all those pots correctly during installation at the site.

I'm hoping this mix of mechanical and digital pots will handle common real-world level control situations.

Will the new controller have Flash EEPROM update capability? User stored speech?

Firmware updates can be downloaded to the controller via the serial port without removing the cover, or being on-site for that matter.

Speech will be built in and will be in the form of digital audio playback rather than synthesized speech. A speech library will be provided, but the customer will be able to add his own digital audio files downloaded over the serial port. No DVR is planned.

Will the new controller have A/D inputs?

The 7330 will have three A/D inputs with a jumper-selectable range of 0 to 5 or 0 to 25 volts. When not used as analog inputs, they can be used as logic inputs. Run-time variables and templates will allow the values to be spoken.

Will the new controller have an Autopatch?

Autopatch is way down on the list due to low interest in autopatches on the part of clubs.

When we produce a new TIM, it'll be in a separate box and will take up a port. That means the pressure will be on us to build controllers with more than three ports, which we understood from the start.

Part of the reason for starting out with three ports instead of more is to evaluate the new "platform" we invented. This platform is scalable to any reasonable number of ports, and we chose to start with three as I've mentioned in a previous message.

What types of capacitors are being used in the new controller?

All audio coupling caps in the 7330 are ceramic to avoid any issues with polarization. Interstage audio coupling is done with 1 uF ceramics, and the TX audio drivers (being low-impedance) use 10 uF ceramics.

All ceramic caps below 0.001 uF are NP0, and the rest are X7R.

There are a few tantalums and electrolytics, and they're used for bypassing only.

Why did you use SMT (Surface Mount Technology) parts?

Common SMT (Surface Mount Technology) components such as resistors, capacitors, and op amps are cheaper and smaller than their leaded counterparts, and for those reasons most of the components in the 7330 controller are SMT.

And while we don't add components to our designs just for the fun of it, in some cases we can build a more robust product by adding a few more SMT parts -- parts that we wouldn't have included in through-hole designs.

For example, the S-COM 5K, 6K, 7K, and some competitive controllers use a single op amp to handle the job of receiver audio interfacing. But getting the right combination of gains and de-emphasis options into one stage for a variety of receiver audio levels can be tricky.

So, each of the three receiver ports in the 7330 feeds two cascaded op amps: The first one handles de-emphasis and the second one handles gain.

A jumper sets up the first op amp to be either a de-emphasis stage with gain or a unity gain buffer.

A second jumper sets up the second op amp to have either "normal" gain (a gain of two to make up for a middle setting of the RX Level pot) or "high" gain (a little over three).

By having two separate stages, we can more easily modify the receiver interface for special applications.

On the other hand, our previous transmitter audio interface scheme used two op amps -- one for mixing and one for driving -- and we did not change that in the 7330. There is now a jumper for choosing "normal" TX gain (a gain of two to make up for the middle setting of the TX Level pot) or "low" gain (a gain of 0.5 for feeding sensitive audio inputs).

Another place where we use more components than other controllers is in the smoothing filters. Vigil designed 5-pole filters for the tone and digital audio generators and 3-pole filters for the CTCSS generators so that the controller would output very clean signals.

And, we used extra parts to buffer each CTCSS encoder's level pot so that the output impedance would be constant at any level.

Are these extra parts really necessary?

You can always look at a specific repeater and design a minimum-parts-count controller for it.

We prefer to sweat the small stuff and make the interface job easier for all those other cases.

How many macros will be supported?

The maximum number of macros hasn't been set, and it's not a hard and fast number anyway (we have more than enough memory; it has more to do with memory partitioning).

What about the software? What's new?

Let me give you an example of the kind of software changes I'm involved with these days.

Everybody knows what an antikerchunker is, right? It requires the user to hold down the mic button for a few seconds to access the machine. Once it's up, the AK is "disarmed" and there is no delay imposed on the following transmissions. At some point after the repeater drops, the AK is "rearmed" and the next transmission is subject to the key-up delay.

A variation is to key the repeater but not send any tail if someone keys and releases during the key-up delay.

The 7330 will support both kinds of antikerchunkers.

Now, the 7K had just one AK, and it was associated with the main port. It monitored RX1 for the key-up delay and it monitored TX1 for the re-arm delay.

Since the 7330 has three full ports, it has three antikerchunkers, one for each receiver.

But it has nine paths, one from each receiver to each transmitter. A receiver can be connected to one, two, or all three transmitters. Which transmitter should determine when the re-arm time starts? If they have different tail durations they'll drop at different times.

I originally wrote the software with three AK'ers, using receiver activity for both the key-up delay and the re-arm delay.

But I realized that if a second receiver (or a tone page, or a long message) keeps the transmitter keyed for a while, the first receiver's antikerchunker will re-arm. The user won't know this and will assume there's no delay on his next transmission, but there will be.

So, we should start the re-arm timer when the transmitter drops, not when the receiver drops. But as I mentioned above, there's a definition problem when the receiver feeds more than one transmitter.

So, the real solution seems to require 9 antikerchunkers -- one for each RX-TX path, not one for each receiver.

That's the kind of 'interesting' problems I'm discovering while doing the multiport software. I'll talk about more software and command issues in the future.