Im working on a hobby project involving an Arduino and TC35 GSM Module, all is going well really but I am wondering is there an AT Command to terminate a voice call (ATD+phone number;) as I cannot seem to find one in any of the literature I've searched through.
Thanks,
Dave
While the "classic" command ATH (there is no need to give a numerical argument to ATH) is applicable for disconnecting calls, notice that it might be configured to do nothing by AT+CVHU=1 (ignore DTR pin and ATH) for other phones (TC35 seems to not support AT+CVHU).
There is the AT+CHUP command that always will hang up the current call, independently of ATH behaviour configuration.
The 27.007 standard also defines an AT+CHCCS (Hangup of current calls) command that can be used to disconnect calls. Also AT+CHLD might be used to disconnect calls.
I think the answer to your question is
ATH0 from memory
The command you are looking for is ATH0 (Also dredged from my memory) but then confirmed with the Official Documentation
ATH command ends call ONLY when call was answered.
AT+CHUP command ends call whenever answered or not
Related
I've been having to come back to a modem I have and sending AT commands to it, and I need to do this programmatically. Sending AT commands works fine if using Minicom, but when using any kind of programatic method it's just super unreliable. I've tried echos and redirection with bash, the atinout program, and the pyserial module in Python, but no matter what sending and receiving commands is iffy at best. It is very rare that I attempt to run the same AT command twice and get consistent output back. I'll get the complete response one time, but then a partial response the next, or maybe no response.
Admittedly I don't know much about serial, so maybe it's my hardware, or maybe the protocol for reading and writing to serial is just unreliable. Can someone please explain how, in general, reading and writing output over a serial port may be unreliable, and any good techniques or libraries to help guarantee a stable flow of reading and writing?
There was another service on my system called ModemManager that was consuming the serial device at the same time I was running through my commands. Once that was disabled all of my programmatic efforts started producing reliable IO to the device.
I'm working on an ESP32 based project that will involve OTA flashes of the ESP.
I know that you can set up different partitions on an ESP32. I'm wondering if it's possible for my code on one partition to then execute code on another partition? (For my usage, I don't need data passed back and forth - just execution handed off from one partition to the other and than given back after execution)
Yes, assuming you don't have Flash encryption with different keys or other tricky copy protection mechanisms enabled. Partitions on Flash are a completely abstract concept for the developers' peace of mind. The CPU doesn't know and doesn't care - it will execute code from anywhere in Flash if told to jump to it.
The challenge here is that you need to convince the linker to find and call a method from an external, hard-coded address. And you need to make sure said method is actually there :) Since this is not a standard solution, you likely won't find a tutorial but have to know your linker really well :)
There's some useful stuff in the ESP IDF linker documentation and probably the GNU linker documentation, if I could find it :)
You will need some freeRTOS information.
I will not write any code here but I can give you some ideas on what you are trying to achieve.
Assume you have two tasks and a digital pin, which is pulled high by the setup() function. You define the task handler for each task. Now you want to change the current running program to some other program, you will check if the digital pin has been LOW for 5 seconds if that's the case , you can use the vTaskSuspend() function in the primary task by providing it the handler of your current task and suspend your current task. Be sure to resume your OTA task by vTaskResume() function before calling vTaskSuspend() . When you have completed the update, restart the esp32 by calling ESP.restart().
If you want to abort the OTA task just pull the same digital pin LOW and using the above method in your OTA task also, you can switch back to your primary task.
I am trying to do an assignment (from another univ's coursepage) which has a line in the starter code (Python with mininet) as
os.system("rmmod tcp_probe; modprobe tcp_probe full=1")
Popen("cat /proc/net/tcpprobe > %s" % (outfile), shell=True)
which gives an error saying that tcp_probe has been disabled.
I found out by googling that tcp_probe has been deprecated in the linux kernel. However it just asks me to 'do the same using ftrace'. I have tried searching online but could not find out how to use ftrace to achieve the same.
Any help is appreciated.
tldr;
Unfortunately, I could not find any way to get TCP tracepoints to work in Mininet, which is what ftrace would uses. The reason for this is that the mininet's /sys/kern/debug directory is empty, i.e., tracing cannot be enabled.
Options:
1. Using mininet-tracing (not recommended)
There probably is a way to get the kernel to include this, or you could use https://github.com/mininet/mininet-tracing which might get you what you need, but I have seen reports that it is slow, and has been updated 9 years ago...
2. Writing a new kernel module (I have tested this and it works)
What I found as a solution instead, was to force printing for the TCP I had in mind and then take a look at the results that way. In order to enable this, you would essentially need to extend some of TCP's behaviour and (quite possibly) reuse the TCP module you have in mind. And create a new kernel module.
Here I have provided an example that you can use. It logs socket information on each ACK. I also included a Makefile and a script to load/unload the kernel module. After you enable the module and let some traffic flow (assuming you are on a debian-based linux) you should be able to find the logs of your TCP in /var/log/kern.log.
Note:
This is a hacky way around the issue, but was good enough for my needs, and hopefully can help someone else too.
Which signal does gdb send when attaching to a process? Does this work the same for different UNIXes. E.g. Linux and Mac OS X?
So far I only found out, that SIGTRAP is used to implement breakpoints. Is it used for attaching aswell?
AFAIK it does not need any signals to attach. It just suspends the "inferior" by calling ptrace. It also reads debugged process memory and registers using this calls and it can request instruction single stepping (provided it's implemented on that port of linux), etc.
Software breakpoints are implemented by placing at right location instruction that triggers "trap" or something similar when reached, but debugged process can run full speed until then.
Also (next to reading man ptrace, as already mentioned) see ptrace explanation on wikipedia.
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.