I have an SMS Appliaction, which receives the messages through GPS Modem and revert back through GPS Modem. The Modem is using COM1.
Now, i need two more appliactions which can send messages through the same GPS Modem. I tried making a webservice which can access the COM1 to send data, but when i try to connect through webService, it throw an error saying, 'COM1 is already occupied, Access denied.'.
Can anybody help me to connect through the modem in above scenario.
Khushi
You have to make sure only 1 connection is made.
Easiest (and most low-tech, but probably most flexible) is having a script checking a directory for files regularly and sending the messages in the file to the modem. The webservice then just writes a file for every SMS it received. (this can be trivially extended to accept emails, web requests, etc, ...)
A bit more sophistacated is to start a thread to do the communication and push the messages on a FIFO like datastructure provided by your favorite programming platform. A BlockinQueue would be perfect. The thread reads the messages from the queue and sends them to the GSM modem.
If you want to have confirmation the SMS is sent (which in my experience does not mean anything and certainly not that the recipient actually received it) you'll need to find a way to return feedback to the caller. This can be as simple a setting a boolean flag in the message to sending another message or performing a callback. But I would not bother. I had situations where 30% of messages dissapeared even when we had confirmation of the message central.
Related
I hit a deadened trying to receive sms on the SIM800L module with Arduino Uno.
I'm using the Receive sms sketch on the IDE, the module does not receive incoming messages and just keeps displaying one sms over and over, this message is the first one I sent to the module, and somehow it's stuck in memory. the sms.flush() method does't erase the message, how do I go about clearing memory to create space for incoming messages ? Thanks
The SIM800L has a vendor specific command to delete all messages, this may clear up enough space for it to receive additional messages.
Run AT+CMGDA=? to find out which mode you need to use. The modem responds with (1-6) or lists the responses in text mode.
Then run AT+CMGDA=6 if the modem responded with numbers, or AT+CMGDA="DEL ALL".
To avoid overflowing the storage, using AT+CNMI=2,2 you can tell the modem to always forward incoming messages to the terminal and avoid storing them in the SIM card or modem memory.
my company uses the application PRTG from paessler.com to monitor several SNMP sensors, I need to monitor the voltage of some devices and transmit it to the manager.
I was going to use an ESP8266 programmed via arduino to do it.
So far I've been able to send data to the ESP via UDP, and I configured it in the manager so it can retrieve the information from it and ping it.
The ping tests are successful however the monitoring does not work, by using the serial interface I can see that the ESP is receiving the data from the manager, with the OID that was set up. But the monitor shows it as inactive, I set up the ESP to send a simple string in the response.
When using a program called Packet Sender I am able to send the udp packets and receive the response as well, and everything works fine.
The ports I am using is 161 to receive in the ESP and I made it send to the 161, 123, 1023 as i saw specified in the prtg site
I may be sending the packets trough a port that is not the right one, or maybe I have to put a header before the message so the controller can Interpret it. I am not sure what the error can be. Any help will be apreciated
pretty easy - simply use the http push sensor from PRTG:
https://www.paessler.com/manuals/prtg/http_push_data_sensor
All best
Christian
As I understand, BLE indications are a reliable communications method. How do you know if your indications was not communicated. I am writing code for the peripheral/server and currently when I send a notifications, I get a manual response from the central. I read that if I use indications, the acknowledges take place in the L2CAP layer automatically and communications is therefore faster, but how does my embedded controller know the Bluetooth module was not successful at getting the packet across the link? We are using the Microchip RN4030 Bluetooth module.
Let's make things clear.
The BLE stack looks roughly like the following. The stack has these layers in this order:
Link Layer
HCI (if controller and host are separated)
L2CAP
ATT
GATT
Application
The Link Layer is a reliable protocol in the sense that all packets are protected by a CRC and every packet is acknowledged by the receiving device. If a packet is not acknowledged, it is resent until an acknowledge is received. There can also only be one outstanding packet, which means no reordering of packets are possible. Acknowledges are normally not being presented to upper layers.
The HCI layer is the communication protocol between the controller and the host.
The L2CAP layer does almost nothing if you use the standard MTU size of 23. It has a length header and a type code ("channel") which indicates what type of packet is being sent (usually ATT).
On the ATT level, there are two types of packets that are sent from the server that are not sent as a response to a client request. Those are notifications and indications. Sending one notification or indication has the same "performance" since the type is just a tag of a packet that's sent over the lower layers. The differences are listed below:
Indications:
When an indication packet is sent to the client, the client must acknowledge the packet by sending a confirmation packet when it has received the indication packet. Even if the indication packet is invalid, a confirmation shall be sent back.
Upper layers are not involved sending back the confirmation.
The server may not send a new indication until it has received a confirmation from the previous one.
The only time you won't receive a confirmation after an indication is if the link is dropped (you should then get a disconnected event), or there is some bug in some of the BLE stacks.
After the app has sent an indication, most BLE stack confirms to the app that that a confirmation has been received by the client as that the indication operation has completed.
Notifications:
No ATT layer acknowledges are sent.
"Commands and notifications that are received but cannot be processed, due to buffer overflows or other reasons, shall be discarded. Therefore, those PDUs must be considered to be unreliable." However I have never noticed an implementation actually following this rule, i.e. all notifications are delivered to the application. Or I've never hit the max buffer size.
The GATT layer is mostly a definition of how the attribute protocol should be used and defines a DB structure of characteristics.
Implications
According to my opinion, there are several flaws or issues with the BLE standard. There are two things that might make indications useless and unreliable in practice:
There are no way to send back an error response instead of a confirmation.
The fact that it is the ATT layer that sends back the confirmation directly when it has received the indication, and not the app when it has successfully handled the indication.
This means that if for example, some bug or other issue causing that the BLE stack couldn't send the indication to the app, or your app crashed, or your app found your value to be invalid, there is no way your peripheral can aware of that. Since it got the confirmation it thinks everything is fine.
I can't understand why they defined indications this way. Since the app doesn't send the confirmation but a lower layer does, there seems to be no point at all in having an ATT layer acknowledge instead of just using the Link Layer acknowledge. Both are just acknowledges that the packet has been received halfway of its destination.
If we draw a parallel to a HTTP POST and internet, we could consider the Link Layer acknowledge as when the network card of the destination receives the request and the ATT confirmation as a confirmation that the TCP stack received the packet. You have no way of knowing that your web server software actually did receive your request, and it processed it with success.
The fact that notifications are allowed to be dropped by the receiver is also bad. Normally notifications are used if the peripheral wants to stream a lot of data to the central and then you don't want dropped packets. They should have designed the flow control so that the Link Layer stopped acknowledge incoming packets instead until the app are ready to process the next notifications. This is even already implemented at the LL + HCI + Host layers.
Windows
One interesting thing about at least the Windows BLE stack is, if it receives indications faster than the app processes them it starts to drop the indications as well, even though only notifications should be allowed to be dropped due to "buffer overflows or other reasons". It buffers at most 512 indications in my tests.
That said
Just use notifications and if you want some kind of confirmation, let the client send a write packet when it has received your data and successed processing it.
I would like to process sms messages from my GSM modem (SIM900, but have few others also) but without +CMTI notification.
Code would run in a look and execute various commands, and one of them would be to check if message arrived and then act upon that.
Currently if modem received sms it outpus +CMTI message which get somewhere in the buffer.
Would disabling of that be better approach or should I parse the structure?
Please run
AT+CNMI=0,0,0,0,0
This command silences all SMS URC notifications.
There are pro's and con's with both ways of dealing with receiving and handling SMS messages.
1) Storing on SIM card
There are a couple of downsides with this option. You have to extract the SMS messages from the SIM card which costs time on the one hand. On the other hand it degrades the SIM card itself. Depending on how many SMS's you are receiving this could cause the SIM card to stop working aka no longer able to do read and writes.
2) Handling unsolicited
Here the downside is that you have to be permanently connected to the modem and collect the messages as they come. So if there are USB connection issues it could occur that you lose messages. There are ways of coping with this, for example by configuring the modem so that you manually acknowledge SMS messages received (AT+NACK). This means that the mobile operator network will resend the messages at a later point in time.
When you have modems from different manufacturers then configuration is sometimes a little tricky regarding unsolicited messages. Watch out there if you choose this route. Via AT+CNMI (parameters are different depending on manufacturer/model) you can configure how the modem deals with unsolicited messages. This also involves how the modem handles messages when no "host" is connected to the modem etc... I really recommend finding the AT Command manuals for your modems and seeing what is possible there.
To summarise I personally recommend the unsolicited approach as it's a lot more comfortable handling messages rather than accessing the SIM card to grab and delete received messages.
I'm writing a Linux program (using Qt 4.8 and libusb 1.0) which will communicate with a custom USB device (currently being programmed by a co-worker).
Step 1 is to have a "heartbeat" going back and forth over USB at regular intervals.
I'm currently using asynchronous bulk transfer.
For testing, I've put my "Send_Heartbeat()" on a button click. If I click on the button a LOT and queue up a number of messages to send, as long as I keep my queue busy, the messages keep sending and my USB device keeps receiving them.
If I stop for a few seconds, then resume and add more messages to the queue, the USB device stops receiving them.
BUT, my program's Transfer Callback DOES return with a transfer status code of 0, indicating success, even though my USB device isn't receiving them.
My questions:
Why does the callback's transfer status indicate success if my USB device appears to have stopped receiving them?
Has anyone heard of this type of behaviour?
It's worth noting that if I disconnect the USB device, I get proper status codes returned in my callback indicating that the device has gone away.
If the USB Device is left connected and running, and I "Detatch" and then again "Attach" to force a re-connection and try sending more test heartbeats, it works! The USB device starts receiving messages again.
My "Detatch" is the following calls:
libusb_release_interface()
libusb_reset_device()
libusb_close()
Then my "Attach" is:
libusb_get_device_list()
libusb_get_device_descriptor()
libusb_open()
libusb_set_configuration()
libusb_claim_interface()
My next step is to narrow down which of the libusb commands is re-establishing the communication.
Meanwhile, I'm hoping someone recognizes these symptoms and has a suggestion.
As it's my first time programming USB communication, I'm wondering if there is some fundamental which I've missed.
Thanks!
The issue is here I guess:
My "Detatch" is the following calls:
libusb_release_interface();
In your detatch, you need to attach kernel driver
detatch_kernel_driver();
libusb_reset_device();
libusb_close();
Then my "Attach" is:
libusb_get_device_list();
libusb_get_device_descriptor();
libusb_open();
libusb_set_configuration();
Here you need to check if the kernel driver is active or not. So,
check what attach_kernel_driver(); returns, and call detatch_kernel_driver(); if needed
libusb_claim_interface();