SIM800l - Disable "SMS Ready" and "Call Ready" unsolicited messages - stm32

My problem is related to SIM800 connection messages.
I use the module with STM32 developlment board. Sometimes module is reporting SMS Ready and Call Ready messages respectively. When I start to send AT commands to the module, it may send these messages (it doesn't happens all the times).
However, the commands I previously sent are apparently unrelated (for example HTTP commands), and SMS Ready / Call Ready messages is coming while they are not expected.
Because of this reason, Keil is reporting "Can not access" message in the debug session. Is it possible that disabling these messages when the connection is established? Or it means that module has an unexpected reset?

According to SIM800x modules AT commands guide, SMS ready and Call ready are URCs (unsolicited result codes) sent at startup as soon as the capabilities to deal with SMS and to perform calls respectively are correctly initialized and available.
So this is the first bad news for you: if you see them it probably means that your device reset due to a bug or as a consequence of one of the commands you previously provided.
The second bad news is that on the AT command guide linked above there's no mention of the capability to disable SMS Ready URC.
There's fortunately at least a good news: Call ready can be disabled by means of AT+CIURC command:
AT+CIURC (Enable or Disable Initial URC Presentation)
Syntax: AT+CIURC=<mode>
<mode> : 0 Disable URC presentation - 1 Enable URC presentation
Note: When module is powered on and initialization procedure is over URC "Call Ready" will be presented if is 1.
The guide also mentions the fact that this setting is saved in the profile area. So, in order to make sure it is persistent to reboot, after issuing the command store active profile:
AT&W
OK

For me, receiving a lot of messagens Call and SMS ready was a problem on current not enough to keep the module working.
(You can check it too watching the led blinking, if it blinks 6/7 times and stop for a while and restart over again, you have the same problem)
Just to SIM800 keep working is necessary at least 700mA.
Ps.: You can connect directly to your battery 18650 (3.7V-4.2V).
If you are using TP4056 module, you must remember there is 1A max current. try to connect in parallel more than 1 TP4056.

Related

Handle timeout of GNotifications in Gnome?

My program needs to react to the user not taking any action on a GNotification.
More specificially, a piece of data is written to the database only if the user does not press the "undo" button on the notification sent after the data's creation. My target deployment scenario does have notifications enabled and a real timeout value.
To be precise: Moving the notification "away" / deleting it should also count as such a timeout.
1) Is there a built-in way to 'listen' to notification timeouts?
2) If not, how could I still implement similar behavior?
I would use the D-Bus org.freedesktop.Notifications interface. Although it is still a draft specification, it does appear stable. My experience accessing the D-Bus interface using Vala has been that it is easier to use and gives the full feature set of the specification. GNotification doesn't seem to be as feature complete.
From the draft specification you will see there is an expire_timeout argument of the org.freedesktop.Notifications.Notify method. That should fit your time out requirement, although I've not used it personally. There is also a org.freedesktop.Notifications.NotificationClosed signal that will allow your program to be notified when the notification is closed, including because of a time out or if it was dismissed by the user.
This post about the screen lock re-design for GNOME Shell 3.10 might give some indication of what notifications are capable of. The post includes some screenshots of notifications appearing in the lock screen.

Using socket interface keeps sending overflow warnings

I'm establishing a watch via the socket interface, and then subscribing to changes.
For each incoming PDU, if the map has a "warning" key, I output the warning to the console/user, as the docs suggest.
However, when an overflow happens, it looks like I don't get the "warning" key just once, but instead every incoming PDU has the same warning ("recrawl happened 1 time") over and over (AFAICT?), so I end up spamming the console with the same error message.
For me, it'd be preferable if Watchman only sent the "warning" key once per overflow event. Otherwise I'm looking at having to cache the "warnings already shown to the user" to avoid spamming the console.
Also, in terms of overflow behavior in general, the warning says:
To resolve, please review the information on
https://facebook.github.io/watchman/docs/troubleshooting.html#recrawl
To clear this warning, run:
`watchman watch-del ... ; watchman watch-project ...`
But I'd prefer to have a way to reset the warning without having to cancel and resubscribe my subscription. E.g. right now I have to control-c kill my program, run the watchman watch-del command, then restart my program.
Which I could automate internally, e.g. have my program detect the "overflow happened" warning message, kill it's subscription, issue a watch-del, and then re-issue the watch.
But, even if I could reset the warning via the socket interface, or do this internal watch-del, I'm wondering why the warning needs reset at all--e.g. in theory if watchman has already done a recrawl, and I told the user it happened (by logging it to the console), shouldn't things be fine now? Why is the watch-del + re-watch required in the first place?
E.g. as long as overflows are not happening constantly, it seems like watchman doing the recrawl (so gets back in sync with the file system) + issuing one warning PDU should mean everything is back to normal, and my user program could, ideally, stay dumb/simple and just keep getting the post-overflow/post-recrawl PDUs on it's same/existing subscription.
Sorry that this isn't as clear as it could be.
First: you don't strictly have to take action here, as the watchman service already recovered from the overflow.
It's just advising you that you may have a local configuration problem; if you are on Linux you might consider increasing the various inotify sysctl parameters. If you are on the mac there is very little you can do about this. The warning is sticky so that it is forced in the face of the user. We later had users request a way to suppress it, so the suggestion for deleting and restarting the watch was added.
The result was a pretty noisy warning that caused more confusion.
In watchman 4.7 we added a configuration option to turn off this warning: https://facebook.github.io/watchman/docs/config.html#suppress_recrawl_warnings
The intent here is to hide the warning from users that don't know how (or don't have permission) to remediate the system configuration. It works well in conjunction with the (undocumented) perf sampling configuration options that can record and report the volume of recrawls to a site-specific reporting system.

How do I programmatically turn on/off Mute Groups on my Behringer X32?

I've got a Behringer X32 rack, which uses an extension of the OSC (Open Sound Control) protocol. This particular rack communicates via UDP packets on port 10023. A fellow named Patrick Maillot actually has some pretty extensive albeit unofficial documentation of the protocol, including multiple executables you can download to interact with the system (outside of the official Behringer apps).
What I would like to do is pretty simple, though I'm having a hard time getting up to speed with this. I want to be able to mute and subsequently un-mute Mute Group 1 on my device. The mute group is already set up; all I want to do is utilize the protocol to either activate or deactivate it.
I can successfully connect to the rack using the X32_Command.exe program. But wading through the documentation, here's what I came up with as my best guess for which commands I should be sending:
/config/mute/1/ON
/config/mute/1/OFF
However, I don't think I have the syntax right (or maybe I've just got the wrong set of commands altogether), because those don't seem to do anything. In the X32_Command.exe console application I appear to receive the following responses when issuing those commands, respectively:
->X, 20 B: /config/mute/1/ON~~~
->X, 20 B: /config/mute/1/OFF~~
However, nothing actually happens on the rack. The mute group isn't affected at all when I issue these commands. How do I get this working? What am I doing wrong?
Just saw this (better late than never). The correct syntax for X32_Commmand.exe would be (as stated in the documentation):
/config/mute/1 ,i 0
/config/mute/1 ,i 1

Silly WebSphere MQ questions

I have two very basic questions on WebSphere MQ - given that I had been kind of administrating it for past few months I tend to think that these are silly questions
Is there a way to "deactivate" a
queue ? (for example through a
runmqsc command or through the
explorer interface) - I think not. I
think what I can do is just delete
it.
What will happen if I create a
remote queue definition if the real
remote queue is not in place? Will
it cause any issues on the queue
manager? - I think not. I think all
I will have are error messages in
the logs.
Please let me know your thoughts.
Thanks!
1 Is there a way to "deactivate" a
queue?
Yes. You can change the queue attributes like so:
ALTER Q(QUEUE_NAME) PUT(DISABLED) GET(DISABLED)
Any connected applications will receive a return code on the next API call telling them that the queue is no longer available for PUT/GET. If these are well-behaved programs they will then report the error and either end or go into a retry loop.
2 What will happen if I create a
remote queue definition if the real
remote queue is not in place?
The QRemote definition will resolve to a transmit queue. If the message can successfully be placed there your application will receive a return code of zero. (Any unsuccessful PUT will be due to hitting MAXDEPTH or other local problem not connected to the fact that the remote definition does not exist.)
The problem will be visible when the channel tries to deliver the message. If the remote QMgr has a Dead Letter Queue, the message will go there. If not, it will be backed out onto the local XMitQ and the channel will stop.

How can I prevent Windows from catching my Perl exceptions?

I have this Perl software that is supposed to run 24/7. It keeps open a connection to an IMAP server, checks for new mail and then classifies new messages.
Now I have a user that is hibernating his XP laptop every once in a while. When this happens, the connection to the server fails and an exception is triggered. The calling code usually catches that exception and tries to reconnect. But in this case, it seems that Windows (or Perl?) is catching the exception and delivering it to the user via a message box.
Anyone know how I can prevent that kind of wtf? Could my code catch a "system-is-about-to-hibernate" signal?
To clear up some points you already raised:
I have no problem with users hibernating their machines. I just need to find a way to deal with that.
The Perl module in question does throw an exception. It does something like "die 'foo bar'. Although the application is completely browser based and doesn't use anything like Wx or Tk, the user gets a message box titled "poll_timer". The content of that message box is exactly the contents of $# ('foo bar' in this example).
The application is compiled into an executable using perlapp. The documentation doesn't mention anything about exception handling, though.
I think that you're dealing with an OS-level exception, not something thrown from Perl. The relevant Perl module is making a call to something in a DLL (I presume), and the exception is getting thrown. Your best bet would be to boil this down to a simple, replicable test case that triggers the exception (you might have to do a lot of hibernating and waking the machines involved for this process). Then, send this information to the module developer and ask them if they can come up with a means of catching this exception in a way that is more useful for you.
If the module developer can't or won't help, then you'll probably wind up needing to use the Perl debugger to debug into the module's code and see exactly what is going on, and see if there is a way you can change the module yourself to catch and deal with the exception.
It's difficult to offer intelligent suggestions without seeing relevant bits of code. If you're getting a dialog box with an exception message the program is most likely using either the Tk or wxPerl GUI library, which may complicate things a bit. With that said, my guess would be that it would be pretty easy to modify the exception handling in the program by wrapping the failure point in an eval block and testing $# after the call. If $# contains an error message indicating connection failure, then re-establish the connection and go on your way.
Your user is not the exception but rather the rule. My laptop is hibernated between work and home. At work, it is on on DHCP network; at home, it is on another altogether. Most programs continue to work despite a confusing multiplicity of IP addresses (VMWare, VPN, plain old connection via NAT router). Those that don't (AT&T Net Client, for the VPN - unused in the office, necessary at home or on the road) recognize the disconnect at hibernate time (AT&T Net Client holds up the StandBy/Hibernate process until it has disconnected), and I re-establish the connection if appropriate when the machine wakes up. At airports, I use the local WiFi (more DHCP) but turn of the wireless altogether (one physical switch) before boarding the plane.
So, you need to find out how to learn that the machine is going into StandBy or Hibernation mode for your software to be usable. What I don't have, I'm sorry to say, is a recipe for what you need to do.
Some work with Google suggests that ACPI (Advanced Configuration and Power Interface) is part of the solution (Microsoft). APM (Advanced Power Management) may also be relevant.
I've found a hack to avoid modal system dialog boxes for hard errors (e.g. "encountered and exception and needs to close"). I don't know if the same trick will work for this kind of error you're describing, but you could give it a try.
See: Avoiding the “encountered a problem and needs to close” dialog on Windows
In short, set the
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Windows\ErrorMode
registry key to the value “2″.