Sponsored by Creative Control Concepts
 | ||||||||
 |
 |
 |
|
 |
|
 |
|
 |
| Home
Automation FAQ Sponsored by Creative Control Concepts |
|
||||||||||||||||||
|
|
 Home Automation FAQ : HA Equipment : Creative Control Concepts/HCS-II : HCS-DTMF Telephone Interface :
My DTMF board is having trouble sensing a ring... |
| The information below comes from a thread on the HCS newsgroup which sheds a lot of light on how the DTMF board works and why it may be having trouble sensing a ring signal.
| |
| Hello All,
I've never used my telephone interface for answering (until now) and discovered that it would not answer the line. It could dial out, sense dial tone. I went back and read some posts (Grant Baxter had this same problem) logic probed it, check circuit traces !
Still, no answer. So on guess (got a clue from Jeff Bachiochi post on this) and removed R2 (is this a pull-up, or part of a RC with C1 ?). Works every time !! Ring.. Answer !
Now, should I leave it out or does it need to be a higher value ? I'm sure with it out I'll have timing problems. Does the SC see the interrupt (INT1) and use it as the ring indicator or does it look at the data (D0) on the 74244 and then determine that there is a ring ? On the DAA, if I probe RI and then when the line rings I'll get a series of pulses during the ring. Is this normal ? Or should it be a clean pulse (one-shot) going low at the ring then back to high ? So far it has passed about 30 tests. Thanks, Alan | |
| Yep - that was me. What I've since found (and this is absolutely
repeatable) is that every time the power goes down, the DTMF won't
answer. If I cycle the power, then call the DTMF enough times
(sometimes 2-3, sometimes 20 or so), it will suddenly answer. It will
answer from then on, MOST of the time. Every once in a while it won't
answer after it's been answering for a good long period of time. (Even
though the power didn't go out.) CC told me that it was possible that I had marginal ring voltage (or current? - I don't remember), but I've hooked this thing up straight to the demarcation point without anything else on the line, and it still won't answer when it's having one of its snits, so I don't think that's it. Next time maybe I'll try the R2 trick. grant | |
| From my previous post on this subject, removing R2 did not solve the
problem. From what I've researched (logic probe - next comes the logic
analyzer !) I'll get a pulse train from the DAA - RI when the phone is
ringing, which is correct. But I never seem to see
a change when monitoring U8 pin 6, which is where the latched INT1 is
coming from.
Is there a timing problem from the SC seeing the interrupt or clearing
it? I've tried numerous values for R2 and C1, no luck. I've replaced U8,
U9 and U3. Could the CH1840 be at fault? Is it possible to obtain a
timing diagram ? Thanks, Alan | |
| I had quite a long session with my board and this is what I think it
happens: If I put JP1 on Latch the board will never answer (that is after the board has been switched on and a program loaded). However if I put JP1 on direct and leave the board off for a couple of minutes (very important this) and then I switch it back on, the board will answer all the time even if I put JP1 back to latched (without switching the system off). I have tried all the other funcionality of the board like recognition for busy signal or not answer and both work very well. The only other thing that does not work is the recognition of the Tone Presence but I was expecting this as the tone signal in Italy is quite different from the US one (even some commercial modems are not recognising the Italian Tone Presence signal and you must disable this manually). That's ok as I do not have to use it in XPRESS to dial out. Actually I was surprised to see that the busy and the no answer signals were being recognised properly. Very good!. I have removed R2 and it does not make any difference. I think something is pulling pin 6 of U8 down but this is just a guess. Thanks again, Nic. | |
| Sheesh - do I really want to post this.... So I finally start palying with a Voice and DTMF board on my test system (yes, I didn't get the DTMF & Voice boards until I started selling them - go figure) So the Voice board works great (note to a few of you who have asked - I'm talking with RC Systems regarding firmware upgrades for existing boards. I'll keep you posted. The latest firmware can play music, generate DTMF tones, plus a variety of other stuff) So now that my HCS is talking I figured I'd play around with my DTMF board. Simple really - after a reset and 10 second delay or so, the DTMF board should simply go offhook, check dialtone, and dial my other phone line. When I pick up it (checking the callprogress value) it says something like "Your alarm is triggered" Easy - well, after it goes offhook, it hangs. It never dials the tones. The system is still 'up', the time increments, and voice commands sent from HOST still get spoken, but the XPRESS stops executing (ie the stuff inside AND OUTSIDE the sequential section) Bizarre. And I can't get it to detect rings either. Did this with multipe DTMF boards and multiple HCS boards. Oh yay! Needless to say I'll be spending much more time with my DTMF board and seeing why it behaves strangly like this. Granted, it my be the way my XPRESS code was written, but all the same. I'll be sure to keep you all posted. Hopefully its my bad coding and not an XPRESS problem :) Mike | |
| > Except for the complete hang, this is very similar to what I've been
> experiencing with the DTMF board. (no dial tone or ring detect)
>
> grant
> And me!!!! No hang but ring detect not working. Except if I put the JP1 into direct (vs. latched) and I switch off the system for a little while (about 20 secs) then when I put the system online again it will work (even if I put the JP1back into latched without switching the system off). I am not sure if I have to reload the program or just leave it there (after quite a long test session I got a bit tired of trying all the combinations out). Nic. | |
| Update on the DTMF problem (Grant, Nicola). It seems that the signal
from RI on the CH1840 DAA is not very clean during the ring. I rigged
up a small board that adds a 74LS14 inverter Schmitt trigger. The board
plugs into U8's socket and duplicates the 74HCT74 with the added 74LS14.
I'll attach a BMP file from the cad drawing. I also added a selection
jumper to either bypass the FF altogether or feed the cleaned up signal
back into the FF. It seems to work much better just bypassing the FF.
I'm not sure what the actual function of the FF is; to supply the
interrupt and also hold a logic level for U3 which is read by the SC?
Maybe, Mike could shed some light on this. This exact circuit
(2 inverting Schmitt triggers in series) is recommended by Cermetek for
the CH1840.
One thing about the board is that it sticks up too far and the DTMF
board has to be on top.
If this works out to be the fix, maybe a ribbon cable for off board
would be better. Alan | |
| Haven't played with mine any more since last weekend, but looking through
the schematics and firmware code, here is what I can tell regarding the
latch. The HCS uses INT1 to signal the start of a ring (as indicated by the CH1840) When INT1 trips low, the 'ring timer' is cleared in XPRESS and the interrupt is disabled. An RTOS task increments this ring timer until 3 seconds is reached. It then increments the ring counter, and clears and re enables the interrupt for the next ring. 'Clearing the interrupt' means clearing the DTMF ring latch by reading the DTMF status register (the LS244 which combines the CS1 and RD signals to the latch clock). The ring timer increments to FF and holds there until it is cleared again by the interrupt. Knowing the DTMF board is used on RTC-180's with whatever firmware the app calls for, the latch may be to queue the interrupt if the firmware masks INT1 at any time. But looking at the HCS firmware, INT1 is never masked so a ring will ALWAYS clear the ring timer. With this caveat - I'm still learning the firmware and I've only looked into this tonight, it seems like XPRESS should sense a ring without the latch. A ring signal from the CH1840 should always generate an interrupt on the Z180 which clears the ring counter. Actually, looking at the latch setup, I swear they used a latch to clean up the ring signal AND hold it. Maybe? D is GND. When a ring comes in, the signal LOW hits the latch preset which trips the latch INT1 output low, causing an interrupt. Even if the RI goes high and low again, the latch SHOULD stay stable LOW (according to my datasheet anyway) The only way to clear a ring signal from the latch is to clock the latch (since D is GND) Ah, perhaps the DTMF needs to be in latch mode for foreign countries? Many places have 'double' rings. The latch would hide the double ring since it holds the ring signal for 3 seconds until the firmware clears it. But since the interrupt is disabled, who cares? But in teh US, the ring is 3 seconds anyway so its moot? Wait - now it makes sense. The DTMF latch is used to present the firmware with a 3 second ring signal, even if multiple rings happen (double rings, etc) But the firmware doesn't care since it turns off INT1 for 3 seconds so the ring line can cycle as often as it wants (double rings, triple rings, etc) Sorry for rambling, just kinda wrote this as I researched it. The problem is, it doesn't make sense why the Schmitt triggers made any difference. Unless the ring signal never goes LOW enough for the latch to preload, it shouldn't matter if the ring signal is noisy. Even if you set Ring to Direct on the board. The interrupt is disablled for 3 seconds after the ring starts so a noisy signal won't cause multiple interrupts. However, I can see where problems would happen if the actual ring signal in your house was slightly > 3 seconds (or the HCS timed too fast) But this would simply cause the # of rings presented in XPRESS to be double the true count since the ring timer would cycle twice per ring. But in teh US, I can't see how the latch offers you anything. Sigh. As for the Ring signal being fed into D1 - I can't find where this is ever used in XPRESS. The LS244 is read and used for call progrss only as best I can tell. So the only way the CH1840 RI signal is sensed in the HCS is via INT1. So my guess is the CH1840 ring signal isn't LOW long enough due to noise (or it is LOW enough period) to preload the latch or trip INT1? The fact that they recommend the schmitt trigger seems to support that. As for Alan's board being too high, the DTMF board has to be on top anyway (or should be) given the top entry DTMF jack. One question Alan, you mention it seems to 'work better' without the latch. How so? Are there still times, even with your board, where a ring would load the latch?' Also, for those of you who made it this far - on your DTMF when it won't answer, is PIn 6 of U8 stuck LOW or High? Sorry for the long post, but I figured you all would appreciate the technical dissection. Time for sleep Mike | |
| The plot thickens. Okay, so I played around with my system a little more this morning. No question - the ring signal will never be seen by the SC since the latch output is LOW when the DTMF board powers up. Maybe this is due to noise from the Cermetek module durin startup? I'll try removing the cermetek module andpowering up to see if the latch goes high like it should. Look back at my last message. They way XPRESS detects a ring seems like if the latch powers up LOW, you are done for. 1) Based on the 7474 datasheet, it looks like once the PreSet line is pulled LOW, the outputs STAY stable even if PreSet goes high (say during a ring) 2) The Z180 manual doesn't come out and say it directly either way, but it seems that INT1 is edge triggered meaning if it is held LOW, the CPU will never Interrupt? 3) XPRESS never resets the latch during initialization! The ONLY time the latch is reset is when the DTMF Status port is read and the ONLY time it is read is during a ring cycle (which requires a falling edge on INT1 which won't happen thanks to #2) It is also read during call progress. So if XPRESS never resets the latch to HIGH by reading the DTMFSTS port, the ring signal will never trip INT1 it seems. This seems to make sense based on what others here have said. Grant - you seem to get your board working after a while. Once it starts working it works OK until you power down? That makes sense based on this. Grant, when you get your DTM Fboard working (after your multiple tries), check Pin 6 of U8 and see if it is high. And Alan, I wonder if the schmitt triggers prevent noise form teh cermetek module from tripping hte latch LOW during power up. I'll have to play around more and see. I'm also going to attempt my first XPRESS recompile (not a simple task!) and add a DTMF Status read during init to ensure the latch goes HIGH. I'll keep you posted. Let me know if you all think this makes sense or if I'm off my rocker. Mike | |
| OK. Hope you all aren't sick of this yet :) I'm actually having fun poking around
this stuff! First, I was wrong. INT1 is NOT edge sensitive. Only the NMI is on the Z180. So the way the firmware is written, the latch should reset 3 seconds after reset. The latch definitely goes LOW on power up. This will trip INT1 on power up. The problem I see here is that this will cause XPRESS to sense a ring on power up? Not sure of the impact of this or if it is accounted for elsewhere in the code. I'll have to look into it further. But I definitely think there should be a deliberate reset of the DTMF latch durin initialization just to be safe. I'll do this in the next version of XPRESS. But, I don't think this will fix everything. Read on. It gets wilder. Using my test program (which has acted strange from the start) the latch would NEVER flip HIGH. My guess - its a problem with how I coded the sequential section. When I loaded my normal HCS control code into the test board (no DTMF code or sequential section), the latch flips high after power up EVERY time. It flips high due to a read of DTMFSTS (#A050) which is confirmed by monitoring the CS1 line. I call the board and the latch goes low signalling ring for 3 seconds EVERY time. With my normal HCS code and the latch HIGH, it works great. Phone rings, latch goes low for 3 seconds (1 second longer than the 2 second ring) like it should. It then resets as the SC read A050 and triggers CS1 - thus clocking the latch. There is PLENTY of room for error. A normal ring in the US is 2 seconds followed by 4 seconds of idle (My previous post was wrong about this length) The latch stays low for 3 seconds. I am now convinced the latch is used to clean up the CH1840 rin signal AND to ensure places with double or triple rings (like many US business on PBXs - double ring = outside call) won't cause XPRESS to get confused. XPRESS always sees a 3 second ring pulse regardless of the cycle of the ring line on the CH1840. But back to my testing.... When I put the test code in, it NEVER flips the FF HIGH. I have an onhook command in teh sequential section in an IF statement that uses a flag to tell when the SC resets. I got sneaky and figured I could force the latch high by checking the callprogress command in the same reset IF which is the only other command which reads #A050 (which will reset the latch) It worked, but hung the sequential section. This is where it gets REALLY wild. My test program is simple. The normal section has 3 if thens which send a SAY command to the voice board at 5, 10, and 15 seconds. The sequential section has an if then to answer the phone on ring based on the XPRESS Manual example and another section to dial out after 10 seconds or so. (This has since been commented out) So I toss the callprogress check in the reset if. The latch resets, but (WIERD!!!!) the RS-485 port locks in a transmit state - happens with or without net modules defined! But the voice board keeps talking. Bizarre! I load my normal HCS code, and it all works fine. So, where does this leave us? Well, I'm not 100% sure but I think I've finally gotten pointed in the right direction. For those of you having trouble, try loading your SC with an event file with NO sequential section. Power up and see if the latch goes high like it should. Try commenting out sections of your sequential section to see if it improves the latch behavior. Post what you all find and hopefully we'll get to the bottom of this. I'm starting to think it is related to the way we may code parts of the sequential section (ways that get the firmware confused which prevents the latch from flipping back to high like it should) Mike | |
Here is Alan Claffey's circuit board for his DTMF fix
| |
|
The result of all this is that I will probably include a minor fix to XPRESS to ensure that ring latch is in the proper state so that rings are properly detected.
| |
|
Update
The fix I tried in XPRESS v3.63 did not seem to help all the ring detect problems though it did fix the false latch state problem.
However, if your phone has a normal US ring to it (ie you don't have distinctive ring or sit behind a PBX), try moving the ring jumper from 'Latch' to 'Direct' Numerous users have found this works much better.
| |
 Append to This Answer |
| Previous: |
 When I call the HCS-II, can it talk to me?
|
| Next: |
Can the HCS-DTMF board send pages?
|
| ||||||||||