Hello,
I am in a relatively unique situation and not sure how to proceed. I am not using ncid but my observation in the last weeks has been that this is probably the only place where people understand my issue and can maybe help me.
I am working on a software similar to ncid in function but for my own private use. It is relatively specialized and given the size of ncid it is way more simpler for me to simply write the software on my own. It also is a great (learning) expierence and the software I write I know in and out so that gives me a great perspective on things and gives me way more freedom to act upon my ideas. I hope this is understandable.
I have several issues with it. First off, the more recent one, it sometimes seems to hang right away. In these cases not even minicom can get a response to a simple "AT", and after a few seconds minicom hangs to a point where I cannot get any input out of it. Power-cycling the modem helps (at least 10 seconds wait in between sometimes longer), but often even that takes 2 or three tries.
Then I seem to have flowcontrol issues, evidenced by responses missing first or last characters, or duplicate first characters.
Moreover, and that is the biggest issue I have, when accepting calls the modem goes into data mode, yet the line is still ringing. The modem proceeds to send me "DIGITAL LINE DETECTED" without terminating the datastream or using any DLE shielded code. Later on (I get the message after 3-7 seconds), a few seconds after that, I get DLE DC4 and DLE ETB, neither of which are documented in the manual. The modem in between those messages will continue to print "RING" as it normally would if I wouldn't have accepted the call. Other phones connected to this line will keep ringing. Reading up on it as much as the internet still gives on these messages is that the modem presumably detects overcurrent. I have tried to connect the modem directly to my docsis modem's rj-11 output, no difference. In the manual there is the at-tte command described to set the amperage in mA that will have to be exceeded. Default value is 160, and the max value 255 makes no difference. In an effort to disable this I set the value to 0. In case a call comes in and gets accepted by my software, the modem will immediately hang up audibly on the other side. It is like when this issue appears the phone line is gone for a moment right after the modem accepts the call.
I am not sure what to do at this point. I can't even try the modem on a different phone line as replicating the issue can take an hour at least, and I yet haven't found anymore whose line I can use. This seems to affect roughly every 10th call. Usually this behavior gets triggered around the 30th call, yesterday I gave up after 65 successful calls.
I don't know what causes this (me, the phone line, the modem). I have about two weeks until my amazon return period runs out.
Basically I need a modem with the following featureset:
-Ordable on amazon.de
-Works in Germany
-CallerID
-Can send and receive voice data
-Able to send faxes
-Does not cost a huge amount of money
Normally if minicom has problems with the modem, the modem is defective.
If you have a Caller iD device, does it have problems displaying the Caller iD?
If the modem sometimes goes into data mode with the line still ringing, it did not pick up the line, it may indicate the modem hardware for picking up the line is failing. Coupled with your other problems, I would exchange or get a different modem.
First off thank you for your time and your reply.
Secondly, no, I do not have a dedicated callerid device. My landline phone however displays the callerid with no issues, and so does the modem (most of the time). There is the rare occasion that on a dirty reset (terminating the program without closing the serial port) the first call will not have any callerid reported by the modem.
I don't have any experience with electronics on the technical side, but to me it sounds like there is an intermittent short in the device when this pickup behavior happens. Maybe the design is faulty and there is leakage somewhere that causes interference, I have no clue.
Have you ever experienced anything like this? Also with regards to the issue I am having with flow control?
Lastly, I am familiar with the wiki article explaining the control characters. What worries me in that regard is that the chipset manual clearly defines the transmission modes and lists all acceptable commands and responses, but leaves out these two, as well as not terminating datamode properly apparently (since it gives command mode responses inside the datamode stream without escaping them properly).
Maybe you or someone else can give me a recommendation? I know about the ncid wiki article and the table, however according to the table this modem should have the featureset I am looking for.
I was and am a bit overwhelmed by the size and featureset of ncid, does it actually have the same requirements I have for my modem:
-Parsing responses apart from callerid
-Switching from command to data mode
-Answering-machine like features
What I find interesting as well is that I did not have the apparent flow control issues with minicom so far, even though I precisely replicated the port configuration (Rate, databits, stopbits, parity, method of flow control, and what not). Even after exchanging the lib I use the issue still persists. I have a 20 years old modem that has no flow control issues, however the callerid function is not properly implemented even though it is supported by the cirrus chipset (It will reencode the raw callerid data over and over again in ASCII hex representation, so you will have something like "DMESG: [hexascii] DMESG: [hexascii] First 4 number characters, then an encoding change for the rest of the number [/hexascii]{/hexascii]". So I have at least this as a comparison in regards to flow control.
Furthermore: Are the modems exactly the same in terms of functionality and inner workings if they have the same lsusb return value and chipset version as they are listed on the ncid wiki article? Because in that table the sucess reports seem to vary, I am wondering if people gave up on different points on the way to getting it to finally work or if there are really differences.
Thank you again.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
NCID does not have all of the features of an answering machine. It is largely aimed at getting Caller ID, rejecting some of the calls, and answering some with a recorded message or fax tones. I've thought about doing more, but have not put any work into it.
The modems do not all seem to be the same, even though they have the same chipset inside. I suspect the analog parts differ so that some are better on ADSL or noisy phone lines.
👍
1
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you. You probably have no idea how helpful this is. Specifically the part about the modems not being the same is vital information I could never have gotten without looking really close at a lot of discussions of having a lot of devices to test with.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I managed to fix the flow control issue. I kept asking myself why minicom had apparently no issues even though I used the exact same parameters for the serial connection until I remembered that back when modemmanager was still running I could see it enter the commands into the tty one character at a time.
It turns out if I flush the buffer after each character it fixes the issue I have with the stream the modem sends to me. Nowhere is this mentioned in the 100 page long manual.
It somehow gives me hope to find a solution to the other issue that remains.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
I am in a relatively unique situation and not sure how to proceed. I am not using ncid but my observation in the last weeks has been that this is probably the only place where people understand my issue and can maybe help me.
I am working on a software similar to ncid in function but for my own private use. It is relatively specialized and given the size of ncid it is way more simpler for me to simply write the software on my own. It also is a great (learning) expierence and the software I write I know in and out so that gives me a great perspective on things and gives me way more freedom to act upon my ideas. I hope this is understandable.
My software uses java and the jserialcomm library (I have tried rxtx previously but with the same issues).
The modem I have lsusb lists as a
"ID 0572:1340 Conexant Systems (Rockwell), Inc."
which according to the ncid wiki entry would be this:
https://web.archive.org/web/20151004224558/http://www.lb-link.cn/index.php/products?cid=176
The product I bought on Amazon is this:
https://www.amazon.de/KALEA-INFORMATIQUE-USB-Modem-RJ11-Chipsatz-CONEXANT/dp/B016MXLCEQ/
So it seems to match the first link's "BL-UM03A".
I have several issues with it. First off, the more recent one, it sometimes seems to hang right away. In these cases not even minicom can get a response to a simple "AT", and after a few seconds minicom hangs to a point where I cannot get any input out of it. Power-cycling the modem helps (at least 10 seconds wait in between sometimes longer), but often even that takes 2 or three tries.
Then I seem to have flowcontrol issues, evidenced by responses missing first or last characters, or duplicate first characters.
Moreover, and that is the biggest issue I have, when accepting calls the modem goes into data mode, yet the line is still ringing. The modem proceeds to send me "DIGITAL LINE DETECTED" without terminating the datastream or using any DLE shielded code. Later on (I get the message after 3-7 seconds), a few seconds after that, I get DLE DC4 and DLE ETB, neither of which are documented in the manual. The modem in between those messages will continue to print "RING" as it normally would if I wouldn't have accepted the call. Other phones connected to this line will keep ringing. Reading up on it as much as the internet still gives on these messages is that the modem presumably detects overcurrent. I have tried to connect the modem directly to my docsis modem's rj-11 output, no difference. In the manual there is the at-tte command described to set the amperage in mA that will have to be exceeded. Default value is 160, and the max value 255 makes no difference. In an effort to disable this I set the value to 0. In case a call comes in and gets accepted by my software, the modem will immediately hang up audibly on the other side. It is like when this issue appears the phone line is gone for a moment right after the modem accepts the call.
I am not sure what to do at this point. I can't even try the modem on a different phone line as replicating the issue can take an hour at least, and I yet haven't found anymore whose line I can use. This seems to affect roughly every 10th call. Usually this behavior gets triggered around the 30th call, yesterday I gave up after 65 successful calls.
I don't know what causes this (me, the phone line, the modem). I have about two weeks until my amazon return period runs out.
Basically I need a modem with the following featureset:
-Ordable on amazon.de
-Works in Germany
-CallerID
-Can send and receive voice data
-Able to send faxes
-Does not cost a huge amount of money
Description of the exact setup and code lines can be found here:
https://stackoverflow.com/questions/57958886/at-modem-picks-up-occasionally-phone-keeps-ringing-digital-line-detected
Thank you so so much for your time reading this. Hopefully you can help me somehow.
Thank you in advance
I like cookies and not technical trouble :(
Last edit: Instant Cookie 2019-09-19
Normally if minicom has problems with the modem, the modem is defective.
If you have a Caller iD device, does it have problems displaying the Caller iD?
If the modem sometimes goes into data mode with the line still ringing, it did not pick up the line, it may indicate the modem hardware for picking up the line is failing. Coupled with your other problems, I would exchange or get a different modem.
DC4 and ETB are explained at https://en.wikipedia.org/wiki/Control_character
Hello,
First off thank you for your time and your reply.
Secondly, no, I do not have a dedicated callerid device. My landline phone however displays the callerid with no issues, and so does the modem (most of the time). There is the rare occasion that on a dirty reset (terminating the program without closing the serial port) the first call will not have any callerid reported by the modem.
I don't have any experience with electronics on the technical side, but to me it sounds like there is an intermittent short in the device when this pickup behavior happens. Maybe the design is faulty and there is leakage somewhere that causes interference, I have no clue.
Have you ever experienced anything like this? Also with regards to the issue I am having with flow control?
Lastly, I am familiar with the wiki article explaining the control characters. What worries me in that regard is that the chipset manual clearly defines the transmission modes and lists all acceptable commands and responses, but leaves out these two, as well as not terminating datamode properly apparently (since it gives command mode responses inside the datamode stream without escaping them properly).
Maybe you or someone else can give me a recommendation? I know about the ncid wiki article and the table, however according to the table this modem should have the featureset I am looking for.
I was and am a bit overwhelmed by the size and featureset of ncid, does it actually have the same requirements I have for my modem:
-Parsing responses apart from callerid
-Switching from command to data mode
-Answering-machine like features
What I find interesting as well is that I did not have the apparent flow control issues with minicom so far, even though I precisely replicated the port configuration (Rate, databits, stopbits, parity, method of flow control, and what not). Even after exchanging the lib I use the issue still persists. I have a 20 years old modem that has no flow control issues, however the callerid function is not properly implemented even though it is supported by the cirrus chipset (It will reencode the raw callerid data over and over again in ASCII hex representation, so you will have something like "DMESG: [hexascii] DMESG: [hexascii] First 4 number characters, then an encoding change for the rest of the number [/hexascii]{/hexascii]". So I have at least this as a comparison in regards to flow control.
Furthermore: Are the modems exactly the same in terms of functionality and inner workings if they have the same lsusb return value and chipset version as they are listed on the ncid wiki article? Because in that table the sucess reports seem to vary, I am wondering if people gave up on different points on the way to getting it to finally work or if there are really differences.
Thank you again.
NCID does not have all of the features of an answering machine. It is largely aimed at getting Caller ID, rejecting some of the calls, and answering some with a recorded message or fax tones. I've thought about doing more, but have not put any work into it.
The modems do not all seem to be the same, even though they have the same chipset inside. I suspect the analog parts differ so that some are better on ADSL or noisy phone lines.
Thank you. You probably have no idea how helpful this is. Specifically the part about the modems not being the same is vital information I could never have gotten without looking really close at a lot of discussions of having a lot of devices to test with.
I managed to fix the flow control issue. I kept asking myself why minicom had apparently no issues even though I used the exact same parameters for the serial connection until I remembered that back when modemmanager was still running I could see it enter the commands into the tty one character at a time.
It turns out if I flush the buffer after each character it fixes the issue I have with the stream the modem sends to me. Nowhere is this mentioned in the 100 page long manual.
It somehow gives me hope to find a solution to the other issue that remains.