Problem: Zoom 3095 (U.S.) needs to be unplugged from the USB port before will work. Did try a powered port: no difference. Trying to follow other troubleshooting posts to solve my problem.
Hardware: Raspberry Pi 3 B
Zoom 3095 USB Modem (U.S. version)
USB Keyboard and mouse
The modem is listed both before and after in lsusb as well as dmesg | fgrep ACM . (Looks like I know what I’m doing – just good at ‘cookbooking’!)
As I said the Zoom 3095 modem needs to be unplugged from the USB port and then plugged back in before it will work/be detected by ncidd. That ‘trick’ works both directly into the RPi 3 B as well as a powered USB 2.0 hub. At this point the keyboard and mouse are plugged directly into the RPi and the Zoom Modem is the only device plugged into the powered hub.
I have a USB volt/amp meter (plugs into a USB port, the tested device plugs into the meter):
Zoom Modem 0.06 A
Mouse 0.01 A when active. .00 when not being moved
Keyboard 0.00 A (!!) (even held the CR key down)
I did not notice a difference in the current readings if the modem was working or not working.
What looks significant in the “Before Unplugging” file is the modem is detected and then lost:
Network Port: 3333
TTY port opened: /dev/ttyACM0
TTY port speed: 115200
TTY lock file: /var/lock/LCK..ttyACM0
TTY port control signals enabled
TTY port initialized in ICANON mode.
Checking Modem Capabilities...
TTY port changed to RAW mode.
Sent Modem 20 of 20 characters:
AT Z S0=0 E1 V1 Q0
No Modem Response
No modem found: /dev/ttyACM0
Terminated: 04/04/2018 11:15:30
Sent Modem 6 of 6 characters:
ATH0
Skipped read for a modem response
pi@raspberrypi:~ $
This appears to be the same section after I’ve unplugged and re-plugged the Zoom modem:
Network Port: 3333
TTY port opened: /dev/ttyACM0
TTY port speed: 115200
TTY lock file: /var/lock/LCK..ttyACM0
TTY port control signals enabled
TTY port initialized in ICANON mode.
Checking Modem Capabilities...
TTY port changed to RAW mode.
Sent Modem 20 of 20 characters: <===
AT Z S0=0 E1 V1 Q0
Modem response: 26 characters in 1 read:
AT Z S0=0 E1 V1 Q0
OK
Before the unplugging the modem doesn’t respond to the “AT Z S0=0 E1 V1 Q0” string, I have no idea why and hoping you folks can help.
Thanks!
Barry
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Try looking in your kernel log file (same info as dmesg gives) with "less /var/log/kern.log" and look for the lines where the modem is discovered.
Mine says:
Apr 4 16:33:22 raspberrypi kernel: [ 5.109168] usb 1-1.3: New USB device found, idVendor=0572,
idProduct=1329
Apr 4 16:33:22 raspberrypi kernel: [ 5.109176] usb 1-1.3: New USB device strings: Mfr=1, Produc
t=2, SerialNumber=3
Apr 4 16:33:22 raspberrypi kernel: [ 5.109180] usb 1-1.3: Product: USB Modem
Apr 4 16:33:22 raspberrypi kernel: [ 5.109184] usb 1-1.3: Manufacturer: Conexant
Apr 4 16:33:22 raspberrypi kernel: [ 5.109188] usb 1-1.3: SerialNumber: 24680246
Apr 4 16:33:22 raspberrypi kernel: [ 5.141157] cdc_acm 1-1.3:1.0: ttyACM0: USB ACM device
Apr 4 16:33:22 raspberrypi kernel: [ 5.141781] usbcore: registered new interface driver cdc_acm
Apr 4 16:33:22 raspberrypi kernel: [ 5.141785] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters
Then go looking for other lines that refer to the same USB port. Mine is 1-1.3, so I could type "/1-1.3" to search for more of them in the kern.log
Are there any errors, or other odd messages about the modem?
p.s. My modem won't work if I don't use a 2 amp power supply for the Raspberry Pi 3-B.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
p.s. My modem won't work if I don't use a 2 amp power supply for the Raspberry Pi 3-B.
I've found this to be similarly true on HP EliteDesk 800 G1 SFF onboard USB 2.0 and 3.0 (3.1 gen 1) as well. Had to put in a PCIe USB board with a built in power amplifier or external connection to the systems very low powered PSU. Multiple motherboards tested with the Zoom 3095. I presume if any other PSU is bigger than these SFFs have (~130W) and is actively pulling from the PSU it should work (like in one machine with an 750W PSU) provided there is ample power... otherwise CID never works although the modem is recognized in Ubuntu line under /dev/ttyACM# and NCID does see it... but doesn't seem to work out of the box.
Occasionally some USB 3.0 chipsets won't work well with USB 2.0 devices on another machine tested.
As usual ModemManager service can conflict but that's another thread/subject I've already additionally commented on.
As per the specific subject of this thread, on all machines tested with this modem, I've always had to sudo poweroff the machine before it would work properly with all the NCID versions I've been utilizing (so no reboots unfortunately atm i.e. shutdown or unplug is also my experience). Inconvenient but still worth it since I really appreciate this projects efforts. :) Thank you all!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you for providing such a detailed insight. I never would have thought there would be an issue with USB 2.0 devices and USB 3.0 chipsets; that gives me another thing to suspect when troubleshooting.
I really appreciate this projects efforts. :) Thank you all!
You're very welcome. Thanks for the compliment -- such feedback is what makes it worthwhile to us to keep improving NCID. :-)
Of note, the cake day for the first official distribution of NCID is July 16, 2002. It turned 18 this month. John L. Chmielewski was the sole developer for many years and remains the lead today.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the reply; sorry about the delay: I didn’t have “e-mail notifications” turned on –oops!
I have a copy of kernel log posted at https://pastebin.com/wBKZ3DRu along with some notes at the end. I didn’t see anything different other than I received an error message when the modem worked (!!!):
Apr 6 14:10:23 raspberrypi kernel: [ 128.451544] usb 1-1.4: device descriptor read/64, error -32
The RPi has a wall wart rated 5.25V @ 2500 mA. I removed the powered hub as it didn’t solve the problem (still needed to unplug and re-insert the Zoom Modem); it’s wall wart was rated 5 V @ 2000mA.. ...Just for clarification this entire kernel log is without the powered hub. The 14:07 start is after a shutdown to remove the powered hub. The Zoom USB modem was unplugged and re-inserted at 14:10.
ncid -Dv3 indicated the modem was not connected initially.
What appears to be the important comparison of the kernel log (same as the very end of what I have posted at PasteBin):
Take the ‘good portion’ and try to find a bad match with the initial ‘bad portion’:
Apr 6 14:10:19 raspberrypi kernel: [ 125.241360] usb 1-1.4: USB disconnect, device number 5
Apr 6 14:07:04 raspberrypi kernel: [ 2.251548] usb 1-1.4: new full-speed USB device number 5 using dwc_otg
Apr 6 14:10:22 raspberrypi kernel: [ 128.351550] usb 1-1.4: new full-speed USB device number 7 using dwc_otg
So modem moved from 5 to 7 – normal
Apr 6 14:10:23 raspberrypi kernel: [ 128.451544] usb 1-1.4: device descriptor read/64, error -32
Not found except here, when modem being redetected
Apr 6 14:10:25 raspberrypi kernel: [ 131.135185] usb 1-1.4: New USB device found, idVendor=0803, idProduct=3095
Apr 6 14:07:04 raspberrypi kernel: [ 4.815176] usb 1-1.4: New USB device found, idVendor=0803, idProduct=3095
Is the same
Apr 6 14:10:25 raspberrypi kernel: [ 131.135205] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Apr 6 14:07:04 raspberrypi kernel: [ 4.815193] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Is the same
Apr 6 14:10:25 raspberrypi kernel: [ 131.135214] usb 1-1.4: Product: USB Modem
Apr 6 14:07:04 raspberrypi kernel: [ 4.815202] usb 1-1.4: Product: USB Modem
Is the same
Apr 6 14:10:25 raspberrypi kernel: [ 131.135222] usb 1-1.4: Manufacturer: Conexant
Apr 6 14:07:04 raspberrypi kernel: [ 4.815210] usb 1-1.4: Manufacturer: Conexant
Is the same
Apr 6 14:10:25 raspberrypi kernel: [ 131.135230] usb 1-1.4: SerialNumber: 24680246
Apr 6 14:07:04 raspberrypi kernel: [ 4.815218] usb 1-1.4: SerialNumber: 24680246
Is the same
Apr 6 14:10:25 raspberrypi kernel: [ 131.136338] cdc_acm 1-1.4:1.0: ttyACM0: USB ACM device
Apr 6 14:07:04 raspberrypi kernel: [ 5.617406] cdc_acm 1-1.4:1.0: ttyACM0: USB ACM device
Is the same
I do see several warn/warnings but do not appear to be related to the modem. (Thank goodness for electronic search!!)
Thanks for your assistance!
Barry
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I forgot to ask which Linux distro you were using on your raspberry Pi 3-B. Would it happen to be one that is running ModemManager (like my Ubuntu desktop does) ?
ModemManager tries to talk to the modem after boot, at the same time as ncidd is trying to query the modem, and messes up the answers.
I disabled ModemManager on my Ubuntu desktop with sudo chmod 644 /usr/sbin/ModemManager -- this is described in the NCID User Manual, but I missed it for a long while.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Ed!
According to uname -r my RPi is running 4.14.30-v7+, otherwise the answer is Raspbian. (Told you I'm a 'cookbook novice'! )
As fas as ModemManager, I don't think it's installed. Nothing comes up via command line; I did a find using find / -iname "modemmanager*" 2>/dev/null amd also nothing. And yes, did look at the pull-down menus first!
(Hmm: I did not get an e-mail notification you replied; thought I missed because of dinner.)
Have been keeping busy on this end; the letter I prepared off-line:
Hi Folks, Ed!
Trying to see if I can find anything to help figure out why need to unplug and reconnect the Zoom USB modem. Seems to be a rather common issue per Google – can we become the ons to find the solution??!! :)
Anyway, installed ‘powertop’ on the RPi; to run has to be via sudo. Per what I was reading on-line: Select ‘Tunables’, check ports. “GOOD” = power management on; “BAD” = power management off (want bad)
“Bad Autosuspend for USB device USB modem (Conexant)
So when working mode is correct.
Also listing keyboard. DWC OTG controller, mouse, unknown 0424:ec00. ==> SMSC9512/9514 Fast Ethernet Adapter
“Good” listed devices:
– wireless power saving for interface wlan0
– Bluetooth
– unknown 0424:9514 ==> SMC9514 USB Hub
– wake-on-lan status for device eth0
– wake-on-lan status for device wlan0
So AFAICT nothing significant reported. (Was the same before and after.) Do have a question: should I try toggling the power mode of the SMC9514 Hub?? Don’t want to do something that ends up killing communication with the keyboard!
And in more experimentation I installed USBview. Uploaded the Before Unplug and It Won’t Work and the After Unplugging It Now Works on PasteBin: https://pastebin.com/tuqyYrUz and https://pastebin.com/MA1B0mYF , respectively. I don’t see any differences, though did think it odd the Modem was being reported as a 1.10 device. ...Suppose 56Kbaud isn’t all that fast. (Sure seemed like it at the time!)
OK, that’s it on my end. Thanks in advance!
Barry
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Half-thinking of some sort of an automated way to unplug and re-plug my Zoom USB Modem. What I need is a something like what The Cat In The Hat uses to click together the seatbelts in the Thingamajigger (so maybe a little too much TV with my granddaughter??).
The Thingamajigger being way beyond my mechanical capabilities decided to look into scripts. Found this (elsewhere indicated all USB power was under common/singular control):
<start code="">
Where I found that script says the path has changed, on my system is at /sys/devices/platform/soc.3f980000.usb/buspower
The file contents are simply “Bus Power = 0x1” so it looks like the script would take the Ethernet connection down, write a ‘0’ to buspower to put the USB ports to sleep (turn off), write a ‘1’ to wake them up (turn on), then bring the communications port back up.
So a look at buspower revealed this doesn’t seem to be what I’m looking for as the file was ‘0x1’ immediately after a reboot when ncidd -Dv3 saying the modem isn’t connecting and the same when I disconnected and reconnect the modem and the modem was working.
But for a Thingamajigger!
Barry
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Ed!
<quote>I presume you are booting the rPi by plugging the micro USB cord into the rPi.</quote>
Yes, though technically the wall wart into the power strip to the UPS. (Doesn’t wear out the port and a more solid ‘on’.)
<quote>Does it have the same problem if you reboot it with "sudo reboot" ?</quote>
I’ll have to try! I’ve been rebooting via the GUI. … Yes, error.
<quote>I presume ncidd is being started automatically at boot time.</quote>
Yes, though I’m trying to verify. Not listed in Task Manager, or at least in a way I could see. Unplugged the Zoom USB Modem (to reset it) and immediately the error “MSG: Serial device 4 pos 0 Hung Up, Terminated [time]”
OK, here’s something I had not noted before. Was typing the above, so sequence is booted the RPi, open Terminal and typed “ncidd -Dv3”, yeah-yeah modem fails. At this point wrote the reply and then unplugged and replugged the modem.
Ummm: I think I found the problem! ‘ncidd’ is now showing up in Task Manager! I thought I had it loading at boot! (Need to check that out after lunch – will post this portion.)
<quote>Does it work if you restart ncidd with "sudo /etc/init.d/ncidd restart" ?</quote>
Bet it would!
See you after lunch and some testing!
Barry
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Ed!
<quote>Does it work if you restart ncidd with "sudo /etc/init.d/ncidd restart" ?</quote>
Apparently undoes whatever action is done by the physical unplug/reconnect of the USB modem: Terminal sat with “[…] Restarting ncidd (via systemctl): ncidd.service.” for probably ten seconds before returning to prompt. More importantly I also noticed ‘ncidd’ disappeared from the Task Manager List. Rerunning the restart command now only took about six seconds to return to prompt but ‘ncidd’ still not in Task Manager.Disconnect/reconnect the USB Zoom Modem: still not seeing it in Task Manager. Now we did it: the ncid windows on both the Raspberry Pi and this computer aren’t connecting (can’t open socket error).
At Terminal /etc/init.d/ncidd start responds has started but still nothing showing up in Task Manager and stil getting the socket errors.
Sudo reboot
Terminal: ncid & ==> display indicates is connected (as does the one on this computer)
In Task Manager ‘ncidd’ does not appear.
Unplug/replus modem – hmmm still nothing plus the socket errors
At Terminal “ncidd -Dv3” – now ‘ncidd’ appears in Task Manager plus both displays connecting.
..Redid the ‘sudo update-rc.d ncidd defaults’ command; seems to paus a half-second before returning to prompt (is this correct?)
Reboot using the GUI
Nope: don’t see ‘ncidd’ in Task Manager though the ncid window on this computer is connected.
Called myself, did not display anything (regular Caller ID boxes did)
Unplug USB modem, replug.
The GUI here (remote computer) is erroring with not able to connect to socket.
Needed to run ‘ncidd -Dv3’ to clear the socket error and display the test call. And ncidd displays in Task Manager.
Hope something makes sense out of that.
Barry
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well this is strange: just got two calls and missed both of them. Have Terminal with “ncidd -Dv3” up and it displayed CIDINFO: LINEPOTSRING1TIME15:01:38 but not name nor number; nothing on the ncid GUIs either (not surprised at that as nothing in Terminal).
Before the second call came in I did unplug the USB Modem, which terminated ncidd -Dv3 so reran that. Second call came, in, no CID data detected by NCID but was on the CID phone equipment. (Both calls had CID info on the equipment but not NCID.)
Ah! Remembered I had updated the blacklist this morning. I did run sudo invoke-rc.d ncidd restart.
That give any hints as to what isn’t configured correctly? Thanks!
Barry
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
These are long shots, but it looks like maybe long shots are all that are left to try. :D
Let's see if ncidd really is the only process trying to access the modem.
sudo apt-get install lsof
Then when ncidd terminates, try doing:
sudo lsof /dev/ttyACM0
and see what it shows.
For comparison purposes, here's what I get when running NCID on my RPi Model B+ under Jessie. I don't have a Zoom modem. I also don't know why I get the warning it shows.
lsof: WARNING: can't stat() fuse.gvfsd-fuse file system
/run/user/1000/gvfs
Output information may be incomplete.
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
ncidd 29887 root 4u CHR 166,0 0t0 7641 /dev/ttyACM0
Thanks for the reply! Yes, pretty much looks like longshots. Have been keeping my DSL wire pair busy (pseudo-nerdy joke ) looking for a potential solution, or something that may tell you experts something.
Your Part 1:
sudo apt-get install lsof ==>
Seems familiar – yup, I must have installed some time back
sudo lsof /dev/ttyACM0 ==>
pi@raspberrypi:~ $ sudo lsof /dev/ttyACM0
lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs
Output information may be incomplete.
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
ncidd 848 pi 4u CHR 166,0 0t0 14187 /dev/ttyACM0
pi@raspberrypi:~ $
Look like the only utility using.
Whoa: that was with ncidd on; you wrote ‘terminates’. So “sudo etc/init.d/ncidd stop” to stop. ==> “stopping ncidd (via systemctl: ncidd.service” (Took probably 30 seconds.)
Reran lsof: output is just the first two lines, returns to prompt.
Your Part 2:
Have MiniCom installed already so AT+VCID=1 (Gives the ‘OK” response.)
Couldn’t wait so called myself (cell phone to landline:
Welcome to minicom 2.7
OPTIONS: I18n
Compiled on Apr 22 2017, 09:14:19.
Port /dev/ttyACM0, 15:16:21
Press CTRL-A Z for help on special keys
AT+VCID=1
OK
RING
RING <=== At this point hung up, unplugged the Zoom USB modem, did see Minicom display an error about ACM0. Plugged modem back in, waited, and redialed myself:
RING
RING
Something’s telling me that’s not the way that test was supposed to come out! (The Caller ID devices displayed City, State, and telephone number, as normal.)
Oh: I don’t know if this is significant but I was fiddle-farting the other night and was going though a few of the commands that looked of potential interest and non-destructive in the Conexant AT Commands Manual:
+GCAP - Request Complete Capabilities List
This extended-format command causes the modem to transmit one or more lines of
information text listing additional capabilities command +<name>s , which is intended to
permit the user to identify the overall capabilities of the modem. In particular, if the
modem implements a particular modem control standard that uses Extended Syntax
Commands, and if that modem control standard includes command(s) that indicate
general capabilities, the +<names>(s) of those commands will be reported to the modem
in response to a +GCAP command.
Syntax
+GCAP AT+GCAP gives error!!
Example Responses
+GCAP: +FCLASS, +MS, +ES, +DS
for a data modem that supports all capabilities listed
Tried AT+GCAP and received ‘ERROR’
Know from my 1200 baud modem days not all commands will be supported but figured I’d mention.
Thanks again! (This came out formatted nicer in LibreOffice! I write off-line and then paste the whole thing in here.)
Barry
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Don’t know if significant but if I <Quit> MiniCom then ‘ncidd -Dv3’ works – the Zoom USB modem connects properly. If I <eXit> then I have unplug the modem, replug and run ‘ncidd -Dv3’ again for the modem to connect.
Barry
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Uh oh... we should figure out why no caller ID is being detected.
Ignoring the unlug/replug issue for the moment, have you ever gotten caller ID on the modem?
You mention you have other phone equipment that is showing CID. As a test, and if it is practical, could you try disconnecting the other equipment and connect the Zoom to the wall telephone socket? You'll still need to have the DSL filter in line before the modem (wall <=> DSL filter <=> Zoom). Shutdown ncidd, start up minicom, issue AT+VCID=1 and then try calling yourself.
Your observation about quit vs. exit in minicom is interesting. I know there's a difference in how the two reset control signals. To monitor the signals for either ncidd or minicom, in a separate shell issue stty -a -F /dev/ttyACM0. (It should not be necessary to run as root/sudo.) Look for clocal, crtscts, icanon -- if they are prefixed with a dash, the control signal is disabled, otherwise it is enabled. These signals start being listed about half way down the stty output, below the "flush" line. On my RPi, with ncidd running, I get:
Note that during modem initialization, ncidd does manipulate the control signals (you'll see log messages like "TTY port changed to ICANON mode" and "TTY port changed to RAW mode") until it gets to "End of startup: <date>
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ignoring the unlug/replug issue for the moment, have you ever gotten caller ID on the modem?
Yes – in fact received a phone call in “NCID mode” this morning. And while could be a mechanical issue (bad connection) I’m sort of thinking not as the line cord the modem is plugged in to is connected to a line splitter up here my desk phone and CID unit are also plugged in to.
You mention you have other phone equipment that is showing CID. As a test, and if it is practical, could you try disconnecting the other equipment and connect the Zoom to the wall telephone socket? You'll still need to have the DSL filter in line before the modem (wall <=> DSL filter <=> Zoom). Shutdown ncidd, start up minicom, issue AT+VCID=1 and then try calling yourself.
Well that’s weird: LIS I received a phone call this morning while I was gone and it displayed fine. Just received one and nothing. The ‘ncidd -Dv3’ Terminal display showed “RING CIDINFO: LINEPOTSRING1TIME (time)”. Rings was updated: 1, 2, 3, 4, 0. Nothing changed other than I had just turned on the monitor to start experimenting.
The jump-at difference between the two calls is the first one (detected) happens to be in the ALIAS list and the non-displayed/properly detected on was probably spam as showed on the CID equipment as Unknown Name. But (don’t you love those?!) I’ve received other phone calls not on a list and they’ve displayed but (uh-huh!!) they also had a name displayed.
Your observation about quit vs. exit in minicom is interesting. I know there's a difference in how the two reset control signals. To monitor the signals for either ncidd or minicom, in a separate shell issue stty -a -F /dev/ttyACM0. (It should not be necessary to run as root/sudo.) Look for clocal, crtscts, icanon -- if they are prefixed with a dash, the control signal is disabled, otherwise it is enabled. These signals start being listed about half way down the stty output, below the "flush" line. On my RPi, with ncidd running, I get:
azure-donut:~ pi$ sudo stty -a -F /dev/ttyACM0
speed 115200 baud; rows 0; columns 0; line = 0;
intr = <undef>; quit = <undef>; erase = <undef>; kill = <undef>; eof = <undef>; eol = <undef>; eol2 = <undef>;
swtch = <undef>; start = <undef>; stop = <undef>; susp = <undef>; rprnt = <undef>; werase = <undef>; lnext = <undef>;
flush = <undef>; min = 0; time = 1;
-parenb -parodd -cmspar cs8 hupcl -cstopb cread -clocal crtscts
ignbrk -brkint ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
-isig icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke
azure-donut:~ pi$
Note that during modem initialization, ncidd does manipulate the control signals (you'll see log messages like "TTY port changed to ICANON mode" and "TTY port changed to RAW mode") until it gets to "End of startup: <date>
And not trying to complicate anything but here is the ‘log’ from the ‘ncidd -Dv3’ Terminal screen – just scrolled up and copied. Put in-line comments on what I noted as ‘quirks’. (Have to remember my highlighting, etc., in my LibreOffice prep don’t show when I insert to SorceForge!) ‘BJM’ are my initials and I’ll use as a comment code.
BJM: Call #1. CID displayed as “Davenport, IA, 563-359-xxxx”. The CID displayed the number but I’ll redact as is a real local number though probably spammed. Note no data displayed by NCID.
RING
CIDINFO: LINEPOTSRING1TIME09:59:08
RING
CIDINFO: LINEPOTSRING2TIME09:59:14*
RING
CIDINFO: LINEPOTSRING3TIME09:59:20*
RING
CIDINFO: LINEPOTSRING4TIME09:59:26
CIDINFO: LINEPOTSRING0TIME09:59:32
BJM: Call #2. This is a cellphone number which the CID displayed as “Davenport IA” plus the phone number and NCID displayed as (name) and phone number per ALIAS.
RING
CIDINFO: LINEPOTSRING1TIME10:03:54
DATE = 0412
TIME = 1003
NMBR = 563xxxxxxx
NAME = DAVENPORT,IA
Whitelist empty
Checked Blacklist for match flag=0 ret=0 nmbrmatch=0
CID: DATE04122018TIME1003LINEPOTSNMBR563xxxxxxxMESGNONENAMExxxxxxxx*
RING
CIDINFO: LINEPOTSRING2TIME10:04:00*
RING
CIDINFO: LINEPOTSRING3TIME10:04:06*
RING
CIDINFO: LINEPOTSRING4TIME10:04:12
CIDINFO: LINEPOTSRING0TIME10:04:18
Received: REQ: INFO 563xxxxxxx&&xxxxxxxx&&POTS [04/12/2018 12:17:41]
403 Start of data defining permitted requests
INFO: alias NAMEDEP NOALIAS
Whitelist empty
Checked Blacklist for match flag=1 ret=0 nmbrmatch=0
INFO: neither
INFO: dial 563xxxxxxx&&xxxxxxxx
411 End of response
BJM: Call #3. This was the last call I was talking about. CID display was Unknown Name” “641-426-2845” (Posting that as per Google is a spammer.) Nothing in the ‘ncidd -Dv3 Terminal’:
RING
CIDINFO: LINEPOTSRING1TIME12:27:20
RING
CIDINFO: LINEPOTSRING2TIME12:27:26*
RING
CIDINFO: LINEPOTSRING3TIME12:27:32*
RING
CIDINFO: LINEPOTSRING4TIME12:27:38
CIDINFO: LINEPOTSRING0TIME12:27:44
OK, enough to chew on for a while. Thanks again!
Barry
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm still focused on figuring out why the modem isn't capturing CID consistently. Usually it'll be all-or-nothing -- either the modem always gets RING and CID, or only RING. This is very bizarre.
Another long shot: Do you have a lot of phone equipment connected? Maybe you've reached the maximum Ringer equivalence number.
Do you have another computer you can try the modem on, just for testing? For Windows, I've had good luck using PuTTY.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, the inconsistency has me a bit puzzled also. I wasn’t sure what my “last three calls” section of my previous message could tell; me, nothing; someone with troubleshooting experience, possibly something. The three calls were of three different ‘categories: #1 where something was sent in the name field (city, state), #2 a name in the ALIAS file, #3 ‘nothing’ in the name field (did display as “Unknown Name” on the CID devices). Hopefully I’m not confusing the issue.
As for the REN, shouldn’t be anywhere near 5: last Fall we did loose phone service because half of the wire pair for this number became disconnected at one of street-side junction boxes. The repair tech pretty much knew where the error was with his test equipment but because of time constraints (his repair load) he asked if he could simply move us to a different pair – I agreed and we got phone service back. At the time he also checked DSL speed (slightly above what I’m paying for) and also mentioned no problems re: phone loading (the REN).
Years ago we did have problems with noise on the line – non-audible but the gateway didn’t like it and so my DSL connection would crawl and sometimes even drop out. Eventually complained so much they moved my line to a different computer at the Central Office about 1500 feet down the hill from the house. I’m wondering if that’s occurring again, though I haven’t detected any problems with my DSL.
I’m may have a Windows Laptop available; everything here has pretty much been converted to Linux (Ubuntu). Have a laptop running Ubuntu so will try that – install MiniCom on it so the same between it and the RPi. Will get back to you.
Thanks again for the help and suggestions!
Barry
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Me again! <grin!> Installed minicom on my laptop (“T61”) running Ubuntu 16.04. Followed the instructions from the Raspberry Pi – were halfway handy.
dmesg | fgrep ACM ==> cdc_acm 4-1:1.0: ttyACM0: USB ACM device (so is ttyACM0 on both the RPi and my laptop_
sudo lsof /dev/ttyACM0 ==> no output other than the standard two so no one else using
Oddity: configured MiniCom and then ran Minicom (sudo minicom) but didn’t see the Zoom US Modem. Unplugged the modem, re-inserted (hmm: I’m seeing a pattern!!) and got this:
Welcome to minicom 2.7
OPTIONS: I18n
Compiled on Feb 7 2016, 13:37:27.
Port /dev/ttyACM0, 18:39:37
Press CTRL-A Z for help on special keys
ATAT+CGMI
ERROR
AT+GMI
+GMI: CONEXANT
OK
ATIAT+CGMMAT+GMMAT%IPSYS?
ERROR
AT%IPSYS?AT%IPSYS?ATE0
OK
OK
ERROR
OK
ERROR
56000
OK
ERROR
A few minutes later a call did come in but all that displayed was
RING
RING
Was someone we knew so answered
So the thing needed to be unplugged before it was seen. (I need to test if true again but the phone’s in use – I can get in enough ‘trouble’ accidentally! <gg>) Thought the odd part was the self-typing, though I suppose that’s part of the handshaking (?) going on between minicom and the modem.
...Phone’s still in use. “Get off” isn’t an option <chuckle> so I’ll post. Probably no more playing so have a good night, thanks, and more testing tomorrow.
Barry
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I got all of the notifications from sourceforge all at once. :P
Two thoughts:
1) I think the modem has to be told to do caller ID every time it initializes: AT+VCID=1
2) Yesterday I had a conexant modem plugged directly into a dsl line (without the bandpass filter) and was getting callerid for 2 out of 3 calls. (... at a friend's house, I don't know if it works 100% with the filter right now.)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
<quote>I got all of the notifications from sourceforge all at once. :P </quote>
Gee and I thought I thought I was the only one with screwy stuff happening: for a while I was getting messages from a friend of mine in Nevada “tomorrow”. His time zone is two hours behind me, so my 7 p.m. is his 5 p.m., but his messages for several days were being timestamped something like two or three a.m. the next morning! (Whatever the problem was has been corrected.)
<quote>1) I think the modem has to be told to do caller ID every time it initializes: AT+VCID=1
2) Yesterday I had a conexant modem plugged directly into a dsl line (without the bandpass filter) and was getting callerid for 2 out of 3 calls. (... at a friend's house, I don't know if it works 100% with the filter right now.) </quote>
As for plugging the Zoom modem directly into the DSL line sort of implies a signal strength, possible REN, issue, or else some sort of noise problem. I don’t think that’s the problem here as seems more like an every other call, though I reboot/reconnect/etc., too much to verify that ‘rule’.
Does sort of go with the AT+VCID=1 command. Seems like I noticed something about that command in the past.
How does one insert a command string into NCID so it runs at the end of a call? I’m guessing should be attached to the first ring as might answer right away or the call hangs up immediately.
My apologies as I’m getting further into stuff I barely understand and so making it difficult for me to respond and make sense. I sort of know what’s going on but not enough to express.
Anyway thanks – will see about adding the AT+VCID=1 command (I sort of expect you or someone to provide then answer but I also like to see if I can figure out things.)
Barry
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The coffee is finally kicking in and I remembered what I probably want to do is add AT+VCID=1 to the init$.
What I found this morning is the modem is being recognized immediately, no need to unplug, though it is currently on my laptop for testing with minicom.
Have found a few things I’m not understanding. (Hey! Who said just wait until later! <gg>) The manual page for minicom says the configuration file is supposed to be at /etc/minirc.dfl. No such file, and used find to search for the file elsewhere but no results. Minor issue as can modify via -s and select the ‘Modem and dialing’ option.
In that option the defaults are:
Default Init$: (A) ~^M~AT S7=45 S0=0 L1 V1 X4 &c1 E1 Q0 ^M
(Note: &c1 = lower case)
(Note: I added extra spaces to show better)
I’m not sure/don’t recall what the tilde (~) character does – delay??
In earlier experimentation I noted some blanked commands: the modem would respond “OK” or “ERROR” but without displaying the command string. Blindtype ATE1 turns on echo and fixes that, but isn’t that what the “E1” is supposed to do up there in default Init$?
I haven’t checked to see what the other commands do – will do in a little while. Thinking maybe you folks are seeing something. ...I haven’t done it yet but presuming the “AT+VCID=1” string needs to go in the Init$ (A), for now without the ATtention prefix.
Thanks!
Barry
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Minicom does not install a /etc/minirc.dfl file. You must save the setup to create or modify one after you enter <ctrl-a><o>. You must also be root to create /etc/minirc.dfl.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Folks!
Problem: Zoom 3095 (U.S.) needs to be unplugged from the USB port before will work. Did try a powered port: no difference. Trying to follow other troubleshooting posts to solve my problem.
Hardware: Raspberry Pi 3 B
Zoom 3095 USB Modem (U.S. version)
USB Keyboard and mouse
Before Unplugging: https://pastebin.com/xnKZCxHn
After Unplugging: https://pastebin.com/fcGWEXnA
The modem is listed both before and after in lsusb as well as dmesg | fgrep ACM . (Looks like I know what I’m doing – just good at ‘cookbooking’!)
As I said the Zoom 3095 modem needs to be unplugged from the USB port and then plugged back in before it will work/be detected by ncidd. That ‘trick’ works both directly into the RPi 3 B as well as a powered USB 2.0 hub. At this point the keyboard and mouse are plugged directly into the RPi and the Zoom Modem is the only device plugged into the powered hub.
I have a USB volt/amp meter (plugs into a USB port, the tested device plugs into the meter):
Zoom Modem 0.06 A
Mouse 0.01 A when active. .00 when not being moved
Keyboard 0.00 A (!!) (even held the CR key down)
I did not notice a difference in the current readings if the modem was working or not working.
What looks significant in the “Before Unplugging” file is the modem is detected and then lost:
Network Port: 3333
TTY port opened: /dev/ttyACM0
TTY port speed: 115200
TTY lock file: /var/lock/LCK..ttyACM0
TTY port control signals enabled
TTY port initialized in ICANON mode.
Checking Modem Capabilities...
TTY port changed to RAW mode.
Sent Modem 20 of 20 characters:
AT Z S0=0 E1 V1 Q0
No Modem Response
No modem found: /dev/ttyACM0
Terminated: 04/04/2018 11:15:30
Sent Modem 6 of 6 characters:
ATH0
Skipped read for a modem response
pi@raspberrypi:~ $
This appears to be the same section after I’ve unplugged and re-plugged the Zoom modem:
Network Port: 3333
TTY port opened: /dev/ttyACM0
TTY port speed: 115200
TTY lock file: /var/lock/LCK..ttyACM0
TTY port control signals enabled
TTY port initialized in ICANON mode.
Checking Modem Capabilities...
TTY port changed to RAW mode.
Sent Modem 20 of 20 characters: <===
AT Z S0=0 E1 V1 Q0
Modem response: 26 characters in 1 read:
AT Z S0=0 E1 V1 Q0
OK
Before the unplugging the modem doesn’t respond to the “AT Z S0=0 E1 V1 Q0” string, I have no idea why and hoping you folks can help.
Thanks!
Barry
Try looking in your kernel log file (same info as dmesg gives) with "less /var/log/kern.log" and look for the lines where the modem is discovered.
Mine says:
Apr 4 16:33:22 raspberrypi kernel: [ 5.109168] usb 1-1.3: New USB device found, idVendor=0572,
idProduct=1329
Apr 4 16:33:22 raspberrypi kernel: [ 5.109176] usb 1-1.3: New USB device strings: Mfr=1, Produc
t=2, SerialNumber=3
Apr 4 16:33:22 raspberrypi kernel: [ 5.109180] usb 1-1.3: Product: USB Modem
Apr 4 16:33:22 raspberrypi kernel: [ 5.109184] usb 1-1.3: Manufacturer: Conexant
Apr 4 16:33:22 raspberrypi kernel: [ 5.109188] usb 1-1.3: SerialNumber: 24680246
Apr 4 16:33:22 raspberrypi kernel: [ 5.141157] cdc_acm 1-1.3:1.0: ttyACM0: USB ACM device
Apr 4 16:33:22 raspberrypi kernel: [ 5.141781] usbcore: registered new interface driver cdc_acm
Apr 4 16:33:22 raspberrypi kernel: [ 5.141785] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters
Then go looking for other lines that refer to the same USB port. Mine is 1-1.3, so I could type "/1-1.3" to search for more of them in the kern.log
Are there any errors, or other odd messages about the modem?
p.s. My modem won't work if I don't use a 2 amp power supply for the Raspberry Pi 3-B.
I've found this to be similarly true on HP EliteDesk 800 G1 SFF onboard USB 2.0 and 3.0 (3.1 gen 1) as well. Had to put in a PCIe USB board with a built in power amplifier or external connection to the systems very low powered PSU. Multiple motherboards tested with the Zoom 3095. I presume if any other PSU is bigger than these SFFs have (~130W) and is actively pulling from the PSU it should work (like in one machine with an 750W PSU) provided there is ample power... otherwise CID never works although the modem is recognized in Ubuntu line under
/dev/ttyACM#and NCID does see it... but doesn't seem to work out of the box.Occasionally some USB 3.0 chipsets won't work well with USB 2.0 devices on another machine tested.
As usual ModemManager service can conflict but that's another thread/subject I've already additionally commented on.
As per the specific subject of this thread, on all machines tested with this modem, I've always had to
sudo poweroffthe machine before it would work properly with all the NCID versions I've been utilizing (so no reboots unfortunately atm i.e. shutdown or unplug is also my experience). Inconvenient but still worth it since I really appreciate this projects efforts. :) Thank you all!Hi mmartz,
Thank you for providing such a detailed insight. I never would have thought there would be an issue with USB 2.0 devices and USB 3.0 chipsets; that gives me another thing to suspect when troubleshooting.
I've added a link to your post from the NCID Wikipedia Article as Note B(2).
You're very welcome. Thanks for the compliment -- such feedback is what makes it worthwhile to us to keep improving NCID. :-)
Of note, the cake day for the first official distribution of NCID is July 16, 2002. It turned 18 this month. John L. Chmielewski was the sole developer for many years and remains the lead today.
Hi Ed!
Thanks for the reply; sorry about the delay: I didn’t have “e-mail notifications” turned on –oops!
I have a copy of kernel log posted at https://pastebin.com/wBKZ3DRu along with some notes at the end. I didn’t see anything different other than I received an error message when the modem worked (!!!):
Apr 6 14:10:23 raspberrypi kernel: [ 128.451544] usb 1-1.4: device descriptor read/64, error -32
The RPi has a wall wart rated 5.25V @ 2500 mA. I removed the powered hub as it didn’t solve the problem (still needed to unplug and re-insert the Zoom Modem); it’s wall wart was rated 5 V @ 2000mA.. ...Just for clarification this entire kernel log is without the powered hub. The 14:07 start is after a shutdown to remove the powered hub. The Zoom USB modem was unplugged and re-inserted at 14:10.
ncid -Dv3 indicated the modem was not connected initially.
What appears to be the important comparison of the kernel log (same as the very end of what I have posted at PasteBin):
Take the ‘good portion’ and try to find a bad match with the initial ‘bad portion’:
Apr 6 14:10:19 raspberrypi kernel: [ 125.241360] usb 1-1.4: USB disconnect, device number 5
Apr 6 14:07:04 raspberrypi kernel: [ 2.251548] usb 1-1.4: new full-speed USB device number 5 using dwc_otg
Apr 6 14:10:22 raspberrypi kernel: [ 128.351550] usb 1-1.4: new full-speed USB device number 7 using dwc_otg
So modem moved from 5 to 7 – normal
Apr 6 14:10:23 raspberrypi kernel: [ 128.451544] usb 1-1.4: device descriptor read/64, error -32
Not found except here, when modem being redetected
Apr 6 14:10:25 raspberrypi kernel: [ 131.135185] usb 1-1.4: New USB device found, idVendor=0803, idProduct=3095
Apr 6 14:07:04 raspberrypi kernel: [ 4.815176] usb 1-1.4: New USB device found, idVendor=0803, idProduct=3095
Is the same
Apr 6 14:10:25 raspberrypi kernel: [ 131.135205] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Apr 6 14:07:04 raspberrypi kernel: [ 4.815193] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Is the same
Apr 6 14:10:25 raspberrypi kernel: [ 131.135214] usb 1-1.4: Product: USB Modem
Apr 6 14:07:04 raspberrypi kernel: [ 4.815202] usb 1-1.4: Product: USB Modem
Is the same
Apr 6 14:10:25 raspberrypi kernel: [ 131.135222] usb 1-1.4: Manufacturer: Conexant
Apr 6 14:07:04 raspberrypi kernel: [ 4.815210] usb 1-1.4: Manufacturer: Conexant
Is the same
Apr 6 14:10:25 raspberrypi kernel: [ 131.135230] usb 1-1.4: SerialNumber: 24680246
Apr 6 14:07:04 raspberrypi kernel: [ 4.815218] usb 1-1.4: SerialNumber: 24680246
Is the same
Apr 6 14:10:25 raspberrypi kernel: [ 131.136338] cdc_acm 1-1.4:1.0: ttyACM0: USB ACM device
Apr 6 14:07:04 raspberrypi kernel: [ 5.617406] cdc_acm 1-1.4:1.0: ttyACM0: USB ACM device
Is the same
I do see several warn/warnings but do not appear to be related to the modem. (Thank goodness for electronic search!!)
Thanks for your assistance!
Barry
I forgot to ask which Linux distro you were using on your raspberry Pi 3-B. Would it happen to be one that is running ModemManager (like my Ubuntu desktop does) ?
ModemManager tries to talk to the modem after boot, at the same time as ncidd is trying to query the modem, and messes up the answers.
I disabled ModemManager on my Ubuntu desktop with sudo chmod 644 /usr/sbin/ModemManager -- this is described in the NCID User Manual, but I missed it for a long while.
Hi Ed!)
According to uname -r my RPi is running 4.14.30-v7+, otherwise the answer is Raspbian. (Told you I'm a 'cookbook novice'!
As fas as ModemManager, I don't think it's installed. Nothing comes up via command line; I did a find using find / -iname "modemmanager*" 2>/dev/null amd also nothing. And yes, did look at the pull-down menus first!
(Hmm: I did not get an e-mail notification you replied; thought I missed because of dinner.)
Have been keeping busy on this end; the letter I prepared off-line:
Hi Folks, Ed!
Trying to see if I can find anything to help figure out why need to unplug and reconnect the Zoom USB modem. Seems to be a rather common issue per Google – can we become the ons to find the solution??!! :)
Anyway, installed ‘powertop’ on the RPi; to run has to be via sudo. Per what I was reading on-line: Select ‘Tunables’, check ports. “GOOD” = power management on; “BAD” = power management off (want bad)
“Bad Autosuspend for USB device USB modem (Conexant) So when working mode is correct. Also listing keyboard. DWC OTG controller, mouse, unknown 0424:ec00. ==> SMSC9512/9514 Fast Ethernet Adapter “Good” listed devices:– wireless power saving for interface wlan0
– Bluetooth
– unknown 0424:9514 ==> SMC9514 USB Hub
– wake-on-lan status for device eth0
– wake-on-lan status for device wlan0
So AFAICT nothing significant reported. (Was the same before and after.) Do have a question: should I try toggling the power mode of the SMC9514 Hub?? Don’t want to do something that ends up killing communication with the keyboard!
And in more experimentation I installed USBview. Uploaded the Before Unplug and It Won’t Work and the After Unplugging It Now Works on PasteBin: https://pastebin.com/tuqyYrUz and https://pastebin.com/MA1B0mYF , respectively. I don’t see any differences, though did think it odd the Modem was being reported as a 1.10 device. ...Suppose 56Kbaud isn’t all that fast. (Sure seemed like it at the time!)
OK, that’s it on my end. Thanks in advance!
Barry
I may have figured out why I wasn't getting notifications: need to click two buttons!
Hi Folks!
Half-thinking of some sort of an automated way to unplug and re-plug my Zoom USB Modem. What I need is a something like what The Cat In The Hat uses to click together the seatbelts in the Thingamajigger (so maybe a little too much TV with my granddaughter??).
The Thingamajigger being way beyond my mechanical capabilities decided to look into scripts. Found this (elsewhere indicated all USB power was under common/singular control):
<start code="">
!/bin/sh
ifdown eth0
sleep 0.1
echo 0 > /sys/devices/platform/bcm2708_usb/buspower
sleep 1
echo 1 > /sys/devices/platform/bcm2708_usb/buspower
sleep 2
ifup eth0
<end code="">
Where I found that script says the path has changed, on my system is at /sys/devices/platform/soc.3f980000.usb/buspower
The file contents are simply “Bus Power = 0x1” so it looks like the script would take the Ethernet connection down, write a ‘0’ to buspower to put the USB ports to sleep (turn off), write a ‘1’ to wake them up (turn on), then bring the communications port back up.
So a look at buspower revealed this doesn’t seem to be what I’m looking for as the file was ‘0x1’ immediately after a reboot when ncidd -Dv3 saying the modem isn’t connecting and the same when I disconnected and reconnect the modem and the modem was working.
But for a Thingamajigger!
Barry
I presume you are booting the rPi by plugging the micro USB cord into the rPi.
Does it have the same problem if you reboot it with "sudo reboot" ?
I presume ncidd is being started automatically at boot time.
Does it work if you restart ncidd with "sudo /etc/init.d/ncidd restart" ?
Hi Ed!
<quote>I presume you are booting the rPi by plugging the micro USB cord into the rPi.</quote>
Yes, though technically the wall wart into the power strip to the UPS. (Doesn’t wear out the port and a more solid ‘on’.)
<quote>Does it have the same problem if you reboot it with "sudo reboot" ?</quote>
I’ll have to try! I’ve been rebooting via the GUI. … Yes, error.
<quote>I presume ncidd is being started automatically at boot time.</quote>
Yes, though I’m trying to verify. Not listed in Task Manager, or at least in a way I could see. Unplugged the Zoom USB Modem (to reset it) and immediately the error “MSG: Serial device 4 pos 0 Hung Up, Terminated [time]”
OK, here’s something I had not noted before. Was typing the above, so sequence is booted the RPi, open Terminal and typed “ncidd -Dv3”, yeah-yeah modem fails. At this point wrote the reply and then unplugged and replugged the modem.
Ummm: I think I found the problem! ‘ncidd’ is now showing up in Task Manager! I thought I had it loading at boot! (Need to check that out after lunch – will post this portion.)
<quote>Does it work if you restart ncidd with "sudo /etc/init.d/ncidd restart" ?</quote>
Bet it would!
See you after lunch and some testing!
Barry
Hi Ed!
<quote>Does it work if you restart ncidd with "sudo /etc/init.d/ncidd restart" ?</quote>
Apparently undoes whatever action is done by the physical unplug/reconnect of the USB modem: Terminal sat with “[…] Restarting ncidd (via systemctl): ncidd.service.” for probably ten seconds before returning to prompt. More importantly I also noticed ‘ncidd’ disappeared from the Task Manager List. Rerunning the restart command now only took about six seconds to return to prompt but ‘ncidd’ still not in Task Manager.Disconnect/reconnect the USB Zoom Modem: still not seeing it in Task Manager. Now we did it: the ncid windows on both the Raspberry Pi and this computer aren’t connecting (can’t open socket error).
At Terminal /etc/init.d/ncidd start responds has started but still nothing showing up in Task Manager and stil getting the socket errors.
Sudo reboot
Terminal: ncid & ==> display indicates is connected (as does the one on this computer)
In Task Manager ‘ncidd’ does not appear.
Unplug/replus modem – hmmm still nothing plus the socket errors
At Terminal “ncidd -Dv3” – now ‘ncidd’ appears in Task Manager plus both displays connecting.
..Redid the ‘sudo update-rc.d ncidd defaults’ command; seems to paus a half-second before returning to prompt (is this correct?)
Reboot using the GUI
Nope: don’t see ‘ncidd’ in Task Manager though the ncid window on this computer is connected.
Called myself, did not display anything (regular Caller ID boxes did)
Unplug USB modem, replug.
The GUI here (remote computer) is erroring with not able to connect to socket.
Needed to run ‘ncidd -Dv3’ to clear the socket error and display the test call. And ncidd displays in Task Manager.
Hope something makes sense out of that.
Barry
Hi Ed, All!
Well this is strange: just got two calls and missed both of them. Have Terminal with “ncidd -Dv3” up and it displayed CIDINFO: LINEPOTSRING1TIME15:01:38 but not name nor number; nothing on the ncid GUIs either (not surprised at that as nothing in Terminal).
Before the second call came in I did unplug the USB Modem, which terminated ncidd -Dv3 so reran that. Second call came, in, no CID data detected by NCID but was on the CID phone equipment. (Both calls had CID info on the equipment but not NCID.)
Ah! Remembered I had updated the blacklist this morning. I did run sudo invoke-rc.d ncidd restart.
That give any hints as to what isn’t configured correctly? Thanks!
Barry
Hi Barry,
These are long shots, but it looks like maybe long shots are all that are left to try. :D
Let's see if
nciddreally is the only process trying to access the modem.Then when
nciddterminates, try doing:and see what it shows.
For comparison purposes, here's what I get when running NCID on my RPi Model B+ under Jessie. I don't have a Zoom modem. I also don't know why I get the warning it shows.
lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs Output information may be incomplete. COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME ncidd 29887 root 4u CHR 166,0 0t0 7641 /dev/ttyACM0You could try eliminating NCID from the picture and test with
minicom. See Network Caller ID / Wiki / Steps to install and configure minicom on a Raspberry Pi.Once installed and configured, issue:
and wait for a call.
Hi Todd!
Thanks for the reply! Yes, pretty much looks like longshots. Have been keeping my DSL wire pair busy (pseudo-nerdy joke) looking for a potential solution, or something that may tell you experts something.
Your Part 1:
sudo apt-get install lsof ==>
Seems familiar – yup, I must have installed some time back
pi@raspberrypi:~ $ sudo lsof /dev/ttyACM0
lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs
Output information may be incomplete.
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
ncidd 848 pi 4u CHR 166,0 0t0 14187 /dev/ttyACM0
pi@raspberrypi:~ $
Look like the only utility using.
Whoa: that was with ncidd on; you wrote ‘terminates’. So “sudo etc/init.d/ncidd stop” to stop. ==> “stopping ncidd (via systemctl: ncidd.service” (Took probably 30 seconds.)
Reran lsof: output is just the first two lines, returns to prompt.
Your Part 2:
Have MiniCom installed already so AT+VCID=1 (Gives the ‘OK” response.)
Couldn’t wait so called myself (cell phone to landline:
Welcome to minicom 2.7
OPTIONS: I18n
Compiled on Apr 22 2017, 09:14:19.
Port /dev/ttyACM0, 15:16:21
Press CTRL-A Z for help on special keys
AT+VCID=1
OK
RING
RING <=== At this point hung up, unplugged the Zoom USB modem, did see Minicom display an error about ACM0. Plugged modem back in, waited, and redialed myself:
RING
RING
Something’s telling me that’s not the way that test was supposed to come out! (The Caller ID devices displayed City, State, and telephone number, as normal.)
Oh: I don’t know if this is significant but I was fiddle-farting the other night and was going though a few of the commands that looked of potential interest and non-destructive in the Conexant AT Commands Manual:
+GCAP - Request Complete Capabilities List
This extended-format command causes the modem to transmit one or more lines of
information text listing additional capabilities command +<name>s , which is intended to
permit the user to identify the overall capabilities of the modem. In particular, if the
modem implements a particular modem control standard that uses Extended Syntax
Commands, and if that modem control standard includes command(s) that indicate
general capabilities, the +<names>(s) of those commands will be reported to the modem
in response to a +GCAP command.
Syntax
+GCAP AT+GCAP gives error!!
Example Responses
+GCAP: +FCLASS, +MS, +ES, +DS
for a data modem that supports all capabilities listed
Tried AT+GCAP and received ‘ERROR’
Know from my 1200 baud modem days not all commands will be supported but figured I’d mention.
Thanks again! (This came out formatted nicer in LibreOffice! I write off-line and then paste the whole thing in here.)
Barry
Hi again Todd!
Don’t know if significant but if I <Quit> MiniCom then ‘ncidd -Dv3’ works – the Zoom USB modem connects properly. If I <eXit> then I have unplug the modem, replug and run ‘ncidd -Dv3’ again for the modem to connect.
Barry
Uh oh... we should figure out why no caller ID is being detected.
ncidd, start upminicom, issueAT+VCID=1and then try calling yourself.minicomis interesting. I know there's a difference in how the two reset control signals. To monitor the signals for eithernciddorminicom, in a separate shell issuestty -a -F /dev/ttyACM0. (It should not be necessary to run as root/sudo.) Look for clocal, crtscts, icanon -- if they are prefixed with a dash, the control signal is disabled, otherwise it is enabled. These signals start being listed about half way down thesttyoutput, below the "flush" line. On my RPi, withnciddrunning, I get:Note that during modem initialization,
ncidddoes manipulate the control signals (you'll see log messages like "TTY port changed to ICANON mode" and "TTY port changed to RAW mode") until it gets to "End of startup: <date>Hi Todd!
Yes – in fact received a phone call in “NCID mode” this morning. And while could be a mechanical issue (bad connection) I’m sort of thinking not as the line cord the modem is plugged in to is connected to a line splitter up here my desk phone and CID unit are also plugged in to.
Well that’s weird: LIS I received a phone call this morning while I was gone and it displayed fine. Just received one and nothing. The ‘ncidd -Dv3’ Terminal display showed “RING CIDINFO: LINEPOTSRING1TIME (time)”. Rings was updated: 1, 2, 3, 4, 0. Nothing changed other than I had just turned on the monitor to start experimenting.
The jump-at difference between the two calls is the first one (detected) happens to be in the ALIAS list and the non-displayed/properly detected on was probably spam as showed on the CID equipment as Unknown Name. But (don’t you love those?!) I’ve received other phone calls not on a list and they’ve displayed but (uh-huh!!) they also had a name displayed.
In a second Terminal: stty -a -F /dev/ttyACM0 :
pi@raspberrypi:~ $ stty -a -F /dev/ttyACM0
speed 115200 baud; rows 0; columns 0; line = 0;
intr = <undef>; quit = <undef>; erase = <undef>; kill = <undef>; eof = <undef>;
eol = <undef>; eol2 = <undef>; swtch = <undef>; start = <undef>; stop = <undef>;
susp = <undef>; rprnt = <undef>; werase = <undef>; lnext = <undef>;
discard = <undef>; min = 0; time = 0;
-parenb -parodd -cmspar cs8 hupcl -cstopb cread -clocal crtscts
ignbrk -brkint ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
-isig icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt
-echoctl -echoke -flusho -extproc
So looks like I have the same.
And not trying to complicate anything but here is the ‘log’ from the ‘ncidd -Dv3’ Terminal screen – just scrolled up and copied. Put in-line comments on what I noted as ‘quirks’. (Have to remember my highlighting, etc., in my LibreOffice prep don’t show when I insert to SorceForge!) ‘BJM’ are my initials and I’ll use as a comment code.
RING
CIDINFO: LINEPOTSRING1TIME09:59:08
RING
CIDINFO: LINEPOTSRING2TIME09:59:14*
RING
CIDINFO: LINEPOTSRING3TIME09:59:20*
RING
CIDINFO: LINEPOTSRING4TIME09:59:26
CIDINFO: LINEPOTSRING0TIME09:59:32
RING
CIDINFO: LINEPOTSRING1TIME10:03:54
DATE = 0412
TIME = 1003
NMBR = 563xxxxxxx
NAME = DAVENPORT,IA
Whitelist empty
Checked Blacklist for match flag=0 ret=0 nmbrmatch=0
CID: DATE04122018TIME1003LINEPOTSNMBR563xxxxxxxMESGNONENAMExxxxxxxx*
RING
CIDINFO: LINEPOTSRING2TIME10:04:00*
RING
CIDINFO: LINEPOTSRING3TIME10:04:06*
RING
CIDINFO: LINEPOTSRING4TIME10:04:12
CIDINFO: LINEPOTSRING0TIME10:04:18
Received: REQ: INFO 563xxxxxxx&&xxxxxxxx&&POTS [04/12/2018 12:17:41]
403 Start of data defining permitted requests
INFO: alias NAMEDEP NOALIAS
Whitelist empty
Checked Blacklist for match flag=1 ret=0 nmbrmatch=0
INFO: neither
INFO: dial 563xxxxxxx&&xxxxxxxx
411 End of response
RING
CIDINFO: LINEPOTSRING1TIME12:27:20
RING
CIDINFO: LINEPOTSRING2TIME12:27:26*
RING
CIDINFO: LINEPOTSRING3TIME12:27:32*
RING
CIDINFO: LINEPOTSRING4TIME12:27:38
CIDINFO: LINEPOTSRING0TIME12:27:44
OK, enough to chew on for a while. Thanks again!
Barry
Hi Barry,
I'm still focused on figuring out why the modem isn't capturing CID consistently. Usually it'll be all-or-nothing -- either the modem always gets RING and CID, or only RING. This is very bizarre.
Another long shot: Do you have a lot of phone equipment connected? Maybe you've reached the maximum Ringer equivalence number.
Do you have another computer you can try the modem on, just for testing? For Windows, I've had good luck using PuTTY.
Hi Todd!
Yes, the inconsistency has me a bit puzzled also. I wasn’t sure what my “last three calls” section of my previous message could tell; me, nothing; someone with troubleshooting experience, possibly something. The three calls were of three different ‘categories: #1 where something was sent in the name field (city, state), #2 a name in the ALIAS file, #3 ‘nothing’ in the name field (did display as “Unknown Name” on the CID devices). Hopefully I’m not confusing the issue.
As for the REN, shouldn’t be anywhere near 5: last Fall we did loose phone service because half of the wire pair for this number became disconnected at one of street-side junction boxes. The repair tech pretty much knew where the error was with his test equipment but because of time constraints (his repair load) he asked if he could simply move us to a different pair – I agreed and we got phone service back. At the time he also checked DSL speed (slightly above what I’m paying for) and also mentioned no problems re: phone loading (the REN).
Years ago we did have problems with noise on the line – non-audible but the gateway didn’t like it and so my DSL connection would crawl and sometimes even drop out. Eventually complained so much they moved my line to a different computer at the Central Office about 1500 feet down the hill from the house. I’m wondering if that’s occurring again, though I haven’t detected any problems with my DSL.
I’m may have a Windows Laptop available; everything here has pretty much been converted to Linux (Ubuntu). Have a laptop running Ubuntu so will try that – install MiniCom on it so the same between it and the RPi. Will get back to you.
Thanks again for the help and suggestions!
Barry
Hi Todd!
Me again! <grin!> Installed minicom on my laptop (“T61”) running Ubuntu 16.04. Followed the instructions from the Raspberry Pi – were halfway handy.
dmesg | fgrep ACM ==> cdc_acm 4-1:1.0: ttyACM0: USB ACM device (so is ttyACM0 on both the RPi and my laptop_
sudo lsof /dev/ttyACM0 ==> no output other than the standard two so no one else using
Oddity: configured MiniCom and then ran Minicom (sudo minicom) but didn’t see the Zoom US Modem. Unplugged the modem, re-inserted (hmm: I’m seeing a pattern!!) and got this:
Welcome to minicom 2.7
OPTIONS: I18n
Compiled on Feb 7 2016, 13:37:27.
Port /dev/ttyACM0, 18:39:37
Press CTRL-A Z for help on special keys
ATAT+CGMI
ERROR
AT+GMI
+GMI: CONEXANT
OK
ATIAT+CGMMAT+GMMAT%IPSYS?
ERROR
AT%IPSYS?AT%IPSYS?ATE0
OK
OK
ERROR
OK
ERROR
56000
OK
ERROR
A few minutes later a call did come in but all that displayed was
RING
RING
Was someone we knew so answered
So the thing needed to be unplugged before it was seen. (I need to test if true again but the phone’s in use – I can get in enough ‘trouble’ accidentally! <gg>) Thought the odd part was the self-typing, though I suppose that’s part of the handshaking (?) going on between minicom and the modem.
...Phone’s still in use. “Get off” isn’t an option <chuckle> so I’ll post. Probably no more playing so have a good night, thanks, and more testing tomorrow.
Barry
I got all of the notifications from sourceforge all at once. :P
Two thoughts:
1) I think the modem has to be told to do caller ID every time it initializes: AT+VCID=1
2) Yesterday I had a conexant modem plugged directly into a dsl line (without the bandpass filter) and was getting callerid for 2 out of 3 calls. (... at a friend's house, I don't know if it works 100% with the filter right now.)
Hi Ed!
<quote>I got all of the notifications from sourceforge all at once. :P </quote>
Gee and I thought I thought I was the only one with screwy stuff happening: for a while I was getting messages from a friend of mine in Nevada “tomorrow”. His time zone is two hours behind me, so my 7 p.m. is his 5 p.m., but his messages for several days were being timestamped something like two or three a.m. the next morning! (Whatever the problem was has been corrected.)
<quote>1) I think the modem has to be told to do caller ID every time it initializes: AT+VCID=1
2) Yesterday I had a conexant modem plugged directly into a dsl line (without the bandpass filter) and was getting callerid for 2 out of 3 calls. (... at a friend's house, I don't know if it works 100% with the filter right now.) </quote>
As for plugging the Zoom modem directly into the DSL line sort of implies a signal strength, possible REN, issue, or else some sort of noise problem. I don’t think that’s the problem here as seems more like an every other call, though I reboot/reconnect/etc., too much to verify that ‘rule’.
Does sort of go with the AT+VCID=1 command. Seems like I noticed something about that command in the past.
How does one insert a command string into NCID so it runs at the end of a call? I’m guessing should be attached to the first ring as might answer right away or the call hangs up immediately.
My apologies as I’m getting further into stuff I barely understand and so making it difficult for me to respond and make sense. I sort of know what’s going on but not enough to express.
Anyway thanks – will see about adding the AT+VCID=1 command (I sort of expect you or someone to provide then answer but I also like to see if I can figure out things.)
Barry
Hi Folks!
The coffee is finally kicking in and I remembered what I probably want to do is add AT+VCID=1 to the init$.
What I found this morning is the modem is being recognized immediately, no need to unplug, though it is currently on my laptop for testing with minicom.
Have found a few things I’m not understanding. (Hey! Who said just wait until later! <gg>) The manual page for minicom says the configuration file is supposed to be at /etc/minirc.dfl. No such file, and used find to search for the file elsewhere but no results. Minor issue as can modify via -s and select the ‘Modem and dialing’ option.
In that option the defaults are:
Default Init$: (A) ~^M~AT S7=45 S0=0 L1 V1 X4 &c1 E1 Q0 ^M
(Note: &c1 = lower case)
(Note: I added extra spaces to show better)
I’m not sure/don’t recall what the tilde (~) character does – delay??
In earlier experimentation I noted some blanked commands: the modem would respond “OK” or “ERROR” but without displaying the command string. Blindtype ATE1 turns on echo and fixes that, but isn’t that what the “E1” is supposed to do up there in default Init$?
I haven’t checked to see what the other commands do – will do in a little while. Thinking maybe you folks are seeing something. ...I haven’t done it yet but presuming the “AT+VCID=1” string needs to go in the Init$ (A), for now without the ATtention prefix.
Thanks!
Barry
Minicom does not install a /etc/minirc.dfl file. You must save the setup to create or modify one after you enter <ctrl-a><o>. You must also be root to create /etc/minirc.dfl.