I recently bought a modem that supports CSD (Circuit Switched Data) calls. I put SIM card in it and I am able to make calls via AT commands. But these are always VOICE calls. I have another modem and I need to connect to it via CSD.
I know it is possible because our colleagues are using it this way to access some network.
They are using windows dial-up connection, but I guess that is just something that in the background calls the AT commands.
Nevertheless the dial-up is still giving me "Error 678: Remote computer did not respond". I have tried many settings, but still the same error. I even tried different computer and still got the same error.
So I found out that when I call CSD, then on the receiving side (if AT+CRC=1) it should display +CRING: REL ASYNC. So I setup another modem and called it and it showed +CRING: VOICE.
So how do I convince my modem to call in the REL ASYNC mode?
I already tried:
AT+IPR=115200 or AT+IPR=9600
AT+FCLASS=0 (this is default though)
AT+CSNS=4
AT+CBST=7,0,0 or AT+CBST=71,0,1
AT^SXRAT=0 (this changes the network to GSM)
But still when I do ATDNUMBERIWANTTOCALL; the receiving side shows +CRING: VOICE.
Also my mobile provider ensured me, that the CSD technology is still supported in my country and that I do not need any kind of special SIM card.
You need to remove the semicolon after the phone number in the ATD command: that semicolon is what tells the modem to make a voice call rather than CSD.
Check with your teleoperator does your sim card have separate data number.
Sometimes postpaid (and/or M2M) cards have three different numbers
1. voice
2. fax
3. data
In the end the number could be called normally like it is written in the question, but it only worked in Germany, not abroad...
Related
I've been working on a device that includes an ESP32. I set up a secure GATT server similar to the Secure Gatt Server Example with a custom service with Man in the Middle (MITM) based encryption. Currently pairing setup is Just Works, and when a client connects to the device they are prompted to pair and thus are bonded with key exchange (although it looks like Justworks disables MITM when I did more investigation for this question).
We do not have any real IO except for one button on the device, but I would like to limit pairing to a certain window of time after the Pairing button is pressed, or to have a "pairing mode" that the device enters (I have worked on another device that may have more of a classic pairing mode that was easier to work with). I know that's not explicitly part of the IDF API, but I'm looking for some guidance on how to approach something like a "pairing mode."
Would setting the IO capability to ESP_IO_CAP_IO work for using a button for the Yes/No? I don't see anything relevant in the documentation about how to configure this. In fact the enum does not appear elsewhere in the IDF sourcecode, nor does the mentioned relevant file stack/btm_api.h help.
Is there a way to disable / enable pairing on command? Would it be some type of change to advertising?
I am looking for a way to do a active Bluetooth LE Scan for a specific MAC / UUID only. In other words: I want the scanresponse of a specific device only. All other (passively) scanned devices should not be asked for scanresponse (to save power).
I saw that HCI has a Whitelist and a Resolvinglist:
Would a whitelist limit scanresponse to the whitelisted devices?
What is the resolvinglist for?
If none of those options work:
If I start a passive scan, is there a way to request scanresponse for a specific device via HCI?
I'm not sure BLE works that way... Regular bluetooth sends additional requests to get details about a device, but I don't think BLE does that. There's only one type scan and I think that's passive.
As for the whitelist, that's for something else. What you can do with the whitelist is put a list of devices in there that you want to automatically connect to. You can then issue a command to initiate connections with all devices found that are in the whitelist. This saves you manually watching for ad packets and issuing separate commands for each device you want to connect to. The whitelist won't affect what you see when scanning.
I'm not sure what the "Resolving List" does, that may do what you want...
EDIT:
Okay, I did some Google searches and it seems like there's an "active" scan for BLE, but I've never used it. If there's a passive/active difference then there must also be a way to query a single device for additional information after doing a passive scan.
Folks
I have two protoypes (say prototype A and B ). Both the prototypes uses Telit GSM modem .
I am using the common SIM to work with both of them.
Problem: If I use the sim with prototype A , AT+CGDCONT, AT#GPRS=1 these commands work perfect . But with Prototype B using the same sim AT+CGDCONT, AT#GPRS=1 don't work .
AT+CGDCONT always echos "operation not allowed" .
So is there any way i can debug this issue ?
Thanks
Ak
You might want to ramp up the error detail. Try setting:
AT+CMEE=1
Most common GSM Modems with a standard AT Command set will then output proper error codes. I have found often such generic messages are then replaced with much more detailed error codes.
Swap the GSM modems and see if the fault moves with the swap. If it does, dump the faulty modem (i.e. replace it to see if that cures the problem). If not the problem may be with your prototype.
It is difficult to guess the reasons. It could be that module B is faulty.
Even though you think both devices are identical, there are settings that might make them different. I remember Telit have commands like AT#SELINT and you have to check whether those settings are the same for both modules. There are a couple of other settings like this which persists after power cycles. If you don't know how to track those differences, you can always format the modules.
Go to Roundsolutions Download section and download the firmware for the module and burn them in using the tools in the same website. After that is done, you will be sure that they are really identical.
A bit of history: We have an application, which was originally written many years ago (1998 is the first date in PVCS but the app is about 5 years older than that as it originally was a DOS program). This application communicates with a piece of hardware via serial. When we got to Windows XP we started receiving reports of the app dying after a short time of running. It seems that the serial comms just 'died' and the app was left in a stuck state. The only way to recover from this situation was to restart the application.
The only information I can find regarding this problem was apparently the Windows Message system would miss that information was received, the buffer would fill and the system would get stuck. This snippet of information was left in a old word document, but there's no evidence to back this up. It also mentions that this is only prevalent at high baud rates (115200+).
The solution was to provide customers with USB->Serial converters along with the hardware.
Today: We are working on a new version of the hardware that will run across a network as well as serial ports. So to allow me to work on the network code, minus the actual hardware we are using a VSCOM NetCom113 device. It also installs a virtual comm port on the users (ie: mine) machine.
Now I have got the network code integrated with the app, it appears that the NetCom device exhibits the same behaviour as a physical commport. This is undesirable as I need the app to run longer than ~30 seconds.
Google turns up zero problems that we experience.
I was wondering:
Has anyone experienced this before? If so what did you do to fix/workaround the problem?
Does anyone have any suggestions as to whether the original author of the document is correct and what I can do to test the theory?
Unfortunately I can't post code as the serial code is tightly couple with the rest of the system, though if you have questions regarding it I can answer questions about it.
Updates:
The code is written using Win32 Comm routines - so I am using CreateFile, ReadFile. There's also judicious calls to GetOverlappedResult.
It's not hanging per se, it's just that the comms stops. You can access the menus, click the buttons, but nothing can interact with the connected hardware. Using realterm you can see that no data is coming in or going out.
I think the reference to the windows message is that the problem is internal to windows. Data has arrived but the kernal has missed it and thus not told the rest of the system about it.
Flow control is not used.
Writing a 'simple' test is difficult due the the fact that the code is tightly coupled and the underlying protocol is quite complex and would require a lot of work.
Are you using DOS-style serial code, or the Win32 CreateFile approach?
If the former, be very suspicious: if at all possible I'd convert to the latter.
If the latter, do you know on what kind of system call it's hanging? Are you in a blocking read call? or an overlapped I/O call? or waiting on an event? (I'm not sure I have enough experience to help, but those are the kinds of questions that come to mind)
You might also check into the queue size, which you can set with the SetupComm function.
I don't buy the "Windows Message system" stuff -- it sounds fishy; you can write good Win32 serial i/o code that never uses Windows messages.
edit: does your Overlapped I/O use events? I seem to remember something about auto-reset events occasionally missing their trigger... check your overlapped I/O calls very carefully to see whether you're handling the possible outcomes properly. Perhaps there's a way to make your code more robust by automatically cancelling the overlapped i/o and restarting another read. (I assume the problem is in the read half, not the write half?)
edit 2: A suggestion: assuming the win32 side has missed a byte or packet, and your devices are in deadlock because they're both expecting each other to respond to something, can you tweak the other side of the serial I/O to regularly send some type of "ping" packet with an incrementing counter? (and log the ping packets on the PC side; that way you can see whether you've missed any)
Are you sure you have your flow control set up correctly? DTR, RTS, etc...
-Adam
i have written apps that use usb / bluetooth serial ports and have never had an issue. with bluetooth i have seen bit rates (sustained) of 800,000 bps for long periods of time. most people don't properly implement the port.
My serial port
Not sure if this is a possibility for you, but if you could re-write the code using C#.NET you'd have access to the SerialPort class there. It might remedy your problem. I know a lot of legacy code based around the Win32 API for hardware I/O ports tended to fail in XP due to timing (had a small bit of experience with MIDI).
In addition, I don't know if you can use the Win32 method of Serial Port access in Vista, so that might shut out future MS OSes from being able to use your code.
What all would be the requirements for the following scenario:
A GSM modem connected to a PC running
a web based (ASP.NET) application. In
the application the user selects a
phone number from a list of phone nos.
When he clicks on a button named the
PC should call the selected phone
number. When the person on the phone
responds he should be able to have a
conversation with the PC user.
Similarly there should be a facility
to send SMS.
Now I don't want any code listings. I just need to know what would be the requirements besides asp.net, database for storing phone numbers, and GSM modem.
Any help in terms of reference websites would be highly appreciated.
I'll pick some points of your very broad question and answer them. Note that there are other points where others may be of more help...
First, a GSM modem is probably not the way you'd want to go as they usually don't allow for concurrency. So unless you just want one user at the time to use your service, you'd probably need another solution.
Also, think about cost issues - at least where I live, providing such a service would be prohibitively expensive using a normal GSM modem and a normal contract - but this is drifting into off-topicness.
The next issue will be to get voice data from the client to the server (which will relay it to the phone system - using whatever practical means). Pure browser based functionality won't be of much help, so you would absolutely need something plugin based.
Flash may work, seeing they provide access to the microphone, but please don't ask me about the details. I've never done anything like this.
Also, privacy would be a concern. While GSM data is encrypted, the path between client and server is not per default. And even if you use SSL, you'd have to convince your users trusting you that you don't record all the conversations going on, but this too is more of a political than a coding issue.
Finally, you'd have to think of bandwidth. Voice uses a lot of it and also it requires low latency. If you use a SIP trunk, you'll need the bandwidth twice per user: Once from and to your client and once from and to the SIP trunk. Calculate with 10-64 KBit/s per user and channel.
A feasible architecture would probably be to use a SIP trunk (they optimize on using VoIP as much as possible and thus can provide much lower rates than a GSM provider generally does. Also, they allow for concurrency), an Asterisk box (http://www.asterisk.org - a free PBX), some custom made flash client and a custom made SIP client on the server.
All in all, this is quite the undertaking :-)
You'll need a GSM library. There appear to be a few of these.
e.g. http://www.wirelessdevstudio.com/eng/
Have a look at the Ekiga project at http://www.Ekiga.org.
This provides audio and or video chat between users using the standard SIP (Session Initiation Protocol) over the Internet. Like most SIP clients, it can also be used to make calls to and receive calls from the telephone network, but this requires an account with a commercial service provider (there are many, and fees are quite reasonable compared to normal phone line accounts).
Ekiga uses the open source OPAL library to implement SIP communications (OPAL has support for several VoIP and video over IP standards - see www.opalvoip.org for more info).