index index

Why in the world would anyone want an RV to talk? I was the first person to create talking broadcast systems, including talking transmitters. If it were not so easy for me to create a talking RV, people would laugh at the effort as if it were misplaced.

EnunBattHot.jpg, 36kB
Here the Solar Controller has alarmed that the Batteries are too hot. In the picture is the Module responsible for the Batteries, and by the bright red LED, the batteries are above 100 F degrees. And no charging is permitted for battery safety.

The Enunciator is a seperate module. And like all modules has a job to do: It talks. The Enunciator verbally speaks in the RV that the Batteries are too hot. All my modules communicate with one another. I was the first person to invent this behavior.

There are other modules that express the need to speak. These include the Master Clock; for example it announces the Day of the Week. Also, the Solar Hot Water System. For example when the hot water pump is on or off.

Enunciator20150902.jpg, 38kB
The Enunciator Module consists of only three chips. This actual board was used 15 years ago at the KHSL-TV Broadcast center. Reporters where verbally told the status of their recorders. Years ago this board contained 60 seconds of a dozen phrases. They included phrases of when to load a new tape. Or when the tape was finished. This small aspect of my Control System was phased out with the advent of recording on hard drives, and no longer discrete tape recorders. The Enunciator in the Taping Room was not the only Enunciator. There were similar Enunciators at Broadcast sites at Cohasset, Tuscan, Redding, and Chico. But all of these versions were "4-chip" designs, giving 4 minutes of syllables, words, and sounds.

Now, I am reusing this Enunciator Module for the RV. It is only a single Voice chip. It is only 60 seconds. It is still over kill for an RV. But I am the creator of the big systems at large Broadcast Plants. So, to install one in my RV is technically trivial.

AnunciateS.gif, 31kB

Here is the overall schematic, minus my communication. I will show you around the block, and explain how it works...
Enun-Address.gif, 6.0kB
Here is the Addressing. For the RV ISD pins 01 and 02 are grounded because that resolution is not needed. With these pins grounded there are 0.469 seconds per cell; that is 60 sec divided by 128 positions. Word length can therefore be multiples of 400mS. I have word lengths of 400mS, 800mS, 1200mS, and 1600mS. These words are prerecorded WAV files on a computer, and they are manipulated in a PC computer with an audio editing program for a proper length, pitch, and amplitude. The words are then automatically inserted into the ISD chip at their proper positions by another program that I wrote.

ISD pin 10 grounded gives both the capability for recording and playback, position agile. It is a "Mode" pin that must be grounded, dictated by the ISD design team. This little board is capable of recording the words and sounds itself. But I record the sounds into the ISD chip at the house with a larger Enunciator similar to this.

Enun-CE.gif, 4.1kB
Once the address is loaded into the ISD, then it can be triggered to play. When I first designed the board, I wanted to make SURE that the trigger came cleanly after the addressing with no bounce or noise. However in subsequent years, I discovered that the 22K resistor and the .01uF cap were not necessary. I handled the delay in software of the PIC.

Enun-Triggery.gif, 10kB
I handled it like this...
Line 310 guarantees that the CE pin is high; It is the down stroke that triggers the event.
Line 311 sets the chip for Playback Mode. Out in the field, installed in an application, this pin Never goes Low.
But here is the delay:
Line 314 to Line 318 contain "NOPs". The instruction does nothing but waists time. It is like a comment. But the effect in this code writing is give time for the addressing of C0, C1, C2, C3, C4, C5, C6, C7 to be well established.

Enunciate-CEDelay.gif, 18kB
Actually, the above was a specific delay, only used for a specific sound. And that sound was "the Attention Getting" sound of a Sonar Ping. A Sonar Ping is played at the beginning of all sentences.

Here is the main delay...
Line 376 to Line 382. This delay is a generic delay; employed for all other sounds.

This is probably a good time to introduce you to my Shifting Buffer. Line 365 loads an Address. That address is contained in Buffers8. And ALL of the pins C0, C1, C2, C3, C4, C5, C6, C7 are configured in one go. I designed it that way.

But now I will show you where I got Buffers8 in line 365.

Enun-Shift.gif, 26kB
A intire packet of information is transmitted on the NET from one module to another. The packets can be of any length up to 255 characters. And a single character can be a word, or even a phrase of several words. So many words may need to be spoken. These are contained in a list of Buffers. The Enunciator goes down the list playing each sound or word, discarding each as they are played. They are considered successfully played as soon as an EOM (End Of Message) is received. The buffers are shifted down to retrieve the next word. It is placed in Buffers8.

In the RV there are only a few modules that may request a sentence to be spoken. But at work there could be a dozen modules all requesting sentences to be enunciated at nearly the same time. What would happen is that the first sentence would start to be spoken, perhaps only a word or two. Then another module would request it's stuff spoken. There is only one Enunciator per NET, so it would clear out the que of the previous buffers, and start speaking from the new que. The effect to human ears was one of stuttering or confusion.

But, in contrast, my RV is very peaceful.

CodeSpeekDayT.gif, 14kB Here is how it looks from the transmitting source. This happens to be from the MasterClock. No transmissions of utterances are immediatly transmitted. There will be delays of milliseconds or even seconds. Each requesting device has a desire or "Need" to have something spoken; but not urgently.

Notice the "nop" at 1615. This is wasted code. I use it if there is a relative goto. If instead, I had used an absolute goto with a Label, I would have suffered waste anyway. The point is that understanding code - the human element - is more important than efficiency.

Enun-Mic.gif, 3.7kB
Originally, there was serious "popping or clicking" between words. There is no solution if you use "ANA" Line Level input. I discovered, by accident, that the clicking could be eliminated by careful adjustments of the AGC, and in religiously using the MIC input. The nature of an audio signal is to have both positive and negative swings. And the ISD chips sits with a DC offset bias of 1.5 volts on the AUX as well as the speaker pins 14 and 15. But this is of course while it is talking. The problem is that at rest AUX goes to zero and 14 and 15 float. A 1k ohm and a .2uF on pin 19 produce a soft gradual reestablishment of the 1.5 volt center bias. It is not abrupt and produces no click. But you can have too much too: For example, a 2uF produces a sluggish attack, and distorts the first part of a word.

Enun-Wave14.jpg, 16kB
Output of either speaker pin 14 or 15. Speaker is 8 ohms. DC center is 1.5 volts. Amplitude is .5v/cm. Amplitude is 1.4vpp on either side of speaker. Total is 2.8 vpp across speaker. Signal is a 1.0 kHz sine wave. Output has a lot of distortion. I tolerate it.

SpeekScreenImage.gif, 46kB
Here is a screen image of the Speech Module as seen on a computer. It is set up for Four chips from years ago, but now works for One in my RV.
From here sounds and words are recorded from a wave file stored on the computer to the Enunciator.
The computer knows the address where it will be placed in the ISD chip. The computer also knows the duration length of the sound.

This Speech, or Enunciator, module has no use of some information; It is Superfluous for its function. For example the Date. You would never guess the reason: With pride, it is there for me. The Date is part of an artifact of my control systems. The date is part of the time. Only a part! As far as what is known, I was the first to Time Stamp events AT THE SOURCE. Many modules also knew the Date, but they ALL knew the Time! I was probably the first Broadcaster to Time Stamp events at all. When Time Stamping finally came along for control systems, in the middle of the 1990's, events were Time Stamped as they were received, and always by a computer. This of course is not accurate at all. A computer located in a city may not know exactly when events happened many miles away. I began the technique of Time Stamping, and it turns out that it would be the most accurate of all. When dozens of events are acting withen the same second, my system Time Stamped each event with an accuracy of a few hundreds of a second. And no computer was involved. An event would be "packaged" with the time of the event - at the source. Each Module had a clock and it was updated at least four times an hour by a Master Clock. My Master Clocks received a radio signal from WWV. All of the Modules, including the Master Clock, were invented by me. I also invented the technique of Autonomous Modules that communicated at will with each other. And of course they all were thirsty for time information from the Master Clock. They constantly needed this information to sync their internal clocks. It was necessary for their existence - like water is to us.

In any case, I still cherish my Modules to have the Time and Date. It is PERSONAL!

RULERMAR.GIF, 1.6kB Here are some examples obtained by placing a microphone near a Enunciator player. I got these from two different players, but the sounds should be nearly the same.

Any of my modules can request something to be spoken to a human(s). It is usually unpredictable, and at the discretion of the individual modules.

Some modules contain redundant functions. For example both the RV (Systems) Module and the Solar (Controller) Module know when th sun is up. The RV module needs it for Solar Hot Water Production. And the Solar Module needs it for Solar Electrical Power and Battery Charging.
from Solar Module: SunBeUp
from Solar Module: Batteries are too Hot
from RV Module: SunBeUp
from RV Module: Inside Air Temperature is too Cold

With all sentences you will notice:
BBALLBLU.GIF, 139B All utterances start with an attention getting sound: in my system it is a Sonar Ping.
BBALLBLU.GIF, 139B All utterances contain the Originating Module.
BBALLBLU.GIF, 139B All utterances end with a "period" sound.

EnunciatorScreen.jpg, 179kB The cosmetics of the Screen...
Been making changes to the screen. Placed a background cene to help identify very quickly exactly what screen one was on. This is the Enunciator screen. Of course it talks without the screen being up, but you can see any of my modules in a visual fashion.