My modem seems to 'forget' that it can do caller id after a period of time. After this happens, I can either restart ncidd or 'cu -l /dev/ttyS0' and exit from 'cu'. Both of these actions cause ncidd to re-initialise the modem and everything works OK again for a while.
I am using a USR 56k Faxmodem in the UK. Is there any modem/ncidd setting I should check for this problem?
When this works I love it, my PC, TiVo and Slimserver all get notified of the number. I am just hoping I can figure out why the modem seems to lose it's settings.
I am running 0.61 on FC4
Thanks,
-- Stuart
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You should read the help forum "it looks good... but no cid" for information on the +GCI modem country command and make sure it is set properly, if your modem has it. The country settings are referenced in the URL given.
It could also be that your modem is re-initializing itself. You could configure the modem so the CID initstring is part of its initialization and see if this fixes the problem.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have tried just about all combinations I can think of for setting the caller id, and the modem still seems to forget. Below is a log for a working ncidd session;
ncidd -Dv
Configured to send 'cidlog' to clients.
Configured to send 'cidinfo' to clients.
Processed config file: /etc/ncid/ncidd.conf
Processed alias file: /etc/ncid/ncidd.alias
CID logfile: /var/log/cidcall.log
Data logfile: /var/log/ciddata.log
TTY port opened: /dev/ttyS0
TTY port speed: 19200
TTY lock file: /var/lock/LCK..ttyS0
TTY port control signals enabled
ATE1V1Q0+GCI=B4
OK
Modem initialized.
AT#CID=1
OK
Modem set for CallerID.
MSG: Started 12/19/2005 19:39
Sent call log: /var/log/cidcall.log
RING
CIDINFO: LINE-RING1*
I guess this is probably not really a ncid problem, but any ideas in keeping the caller id setting would be appreciated before the modem becomes a doorstop!
Thanks,
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have exactly the same problem with the same modem - have you found a workaround? I was thinking of setting up a cron job and sending AT#CID=1 to /dev/modem
Such as echo AT#CID=1 > /dev/modem or similar. How did you query your modem? I run minicom and sometimes it looks like minicom resets the modem it when I quit (I select yes to re-init) and CID=1 is set again.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I do not know what is causing the problem, but I would expect the modem is reinitializing.
The modem should have profiles you can write to with the &W command, usually 0 and 1. You can add the CID initialixation sequence to a profile and make it the default. Then if the modem resets itself, it should enable CID.
If you use the modem for other than NCID, perhaps the lock file is not correct. Normally NCID will see a lock file created, and it will suspend trying to read from the modem. When the lock file goes away, NCID will reinitialize the modem.
If you use minicom and connect to the modem. NCID should generate a message to this effect. When you exit minicom, NCID should generate another message, and then reinitialize the modem. If it does not, then the lock file name is not correct and needs to be set in ncidd.conf.
The cron job is a good workaround, but you should create a lock file, sleep for 1 second, then remove it. NCID should reinitialize the modem. You can also stop and start NCID to accomplish the same thing.
Hope this helps.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
My modem seems to 'forget' that it can do caller id after a period of time. After this happens, I can either restart ncidd or 'cu -l /dev/ttyS0' and exit from 'cu'. Both of these actions cause ncidd to re-initialise the modem and everything works OK again for a while.
I am using a USR 56k Faxmodem in the UK. Is there any modem/ncidd setting I should check for this problem?
When this works I love it, my PC, TiVo and Slimserver all get notified of the number. I am just hoping I can figure out why the modem seems to lose it's settings.
I am running 0.61 on FC4
Thanks,
-- Stuart
You should read the help forum "it looks good... but no cid" for information on the +GCI modem country command and make sure it is set properly, if your modem has it. The country settings are referenced in the URL given.
It could also be that your modem is re-initializing itself. You could configure the modem so the CID initstring is part of its initialization and see if this fixes the problem.
I have tried just about all combinations I can think of for setting the caller id, and the modem still seems to forget. Below is a log for a working ncidd session;
ncidd -Dv
Configured to send 'cidlog' to clients.
Configured to send 'cidinfo' to clients.
Processed config file: /etc/ncid/ncidd.conf
Processed alias file: /etc/ncid/ncidd.alias
CID logfile: /var/log/cidcall.log
Data logfile: /var/log/ciddata.log
TTY port opened: /dev/ttyS0
TTY port speed: 19200
TTY lock file: /var/lock/LCK..ttyS0
TTY port control signals enabled
ATE1V1Q0+GCI=B4
OK
Modem initialized.
AT#CID=1
OK
Modem set for CallerID.
MSG: Started 12/19/2005 19:39
Sent call log: /var/log/cidcall.log
RING
CIDINFO: LINE-RING1*
DATE = 1219
TIME = 1939
NMBR = 07000-123456
RING
CIDINFO: LINE-RING2*
CID: DATE12192005TIME1939LINE-NMBR07000-123456MESGNONENAMEStu (Mobile)*
RING
CIDINFO: LINE-RING3*
RING
CIDINFO: LINE-RING4*
CIDINFO: LINE-RING0*
As you can see, the caller id is interpreted correctly and is passed to the clients correctly.
If I interrogate the modem to check on the caller id status, I get the following reply;
ati4
U.S. Robotics 56K FAX EXT Settings...
B0 E1 F1 L2 M1 Q0 V1 X4 Y0
BAUD=19200 PARITY=N WORDLEN=8
DIAL=TONE ON HOOK CID=1
&A3 &B1 &C1 &D2 &H1 &I0 &K1
&M4 &N0 &P0 &R2 &S0 &T5 &U0 &Y1
S00=000 S01=000 S02=043 S03=013 S04=010 S05=008 S06=004
S07=060 S08=002 S09=006 S10=014 S11=072 S12=050 S13=000
S15=000 S16=000 S18=000 S19=000 S21=010 S22=017 S23=019
S25=005 S27=001 S28=008 S29=020 S30=000 S31=128 S32=002
S33=000 S34=000 S35=000 S36=014 S38=000 S39=012 S40=000
S41=004 S42=010
LAST DIALED #:
OK
At some point later on, the caller id gets reset and the interrogation provides the following result (note the change in the CID line);
ati4
U.S. Robotics 56K FAX EXT Settings...
B0 E1 F1 L2 M1 Q0 V1 X4 Y0
BAUD=19200 PARITY=N WORDLEN=8
DIAL=TONE ON HOOK CID=0
&A3 &B1 &C1 &D2 &H1 &I0 &K1
&M4 &N0 &P0 &R2 &S0 &T5 &U0 &Y1
S00=000 S01=000 S02=043 S03=013 S04=010 S05=008 S06=004
S07=060 S08=002 S09=006 S10=014 S11=072 S12=050 S13=000
S15=000 S16=000 S18=000 S19=000 S21=010 S22=017 S23=019
S25=005 S27=001 S28=008 S29=020 S30=000 S31=128 S32=002
S33=000 S34=000 S35=000 S36=014 S38=000 S39=012 S40=000
S41=004 S42=010
LAST DIALED #:
OK
I guess this is probably not really a ncid problem, but any ideas in keeping the caller id setting would be appreciated before the modem becomes a doorstop!
Thanks,
I have exactly the same problem with the same modem - have you found a workaround? I was thinking of setting up a cron job and sending AT#CID=1 to /dev/modem
Such as echo AT#CID=1 > /dev/modem or similar. How did you query your modem? I run minicom and sometimes it looks like minicom resets the modem it when I quit (I select yes to re-init) and CID=1 is set again.
I do not know what is causing the problem, but I would expect the modem is reinitializing.
The modem should have profiles you can write to with the &W command, usually 0 and 1. You can add the CID initialixation sequence to a profile and make it the default. Then if the modem resets itself, it should enable CID.
If you use the modem for other than NCID, perhaps the lock file is not correct. Normally NCID will see a lock file created, and it will suspend trying to read from the modem. When the lock file goes away, NCID will reinitialize the modem.
If you use minicom and connect to the modem. NCID should generate a message to this effect. When you exit minicom, NCID should generate another message, and then reinitialize the modem. If it does not, then the lock file name is not correct and needs to be set in ncidd.conf.
The cron job is a good workaround, but you should create a lock file, sleep for 1 second, then remove it. NCID should reinitialize the modem. You can also stop and start NCID to accomplish the same thing.
Hope this helps.
Thanks John - I did what you suggested and have a cron task running which touches the modem lock file, sleeps for a second and then removes it.
Works much better now.