+- Charmed Quark Systems, Ltd. - Support Forums and Community (https://www.charmedquark.com/vb_forums)
+-- Forum: General Discussion (https://www.charmedquark.com/vb_forums/forumdisplay.php?fid=3)
+--- Forum: CQC Support (https://www.charmedquark.com/vb_forums/forumdisplay.php?fid=9)
+--- Thread: Serialization of CQC SMS Serial Interface Driver (/showthread.php?tid=10908)
RE: Serialization of CQC SMS Serial Interface Driver - gReatAutomation - 09-15-2019
Great thanks. Will try it out.
RE: Serialization of CQC SMS Serial Interface Driver - gReatAutomation - 09-15-2019
This is a no go as well.. Driver is in an error state when trying to send message.
![[Image: Screen-Shot-2019-09-15-at-12-31-23.jpg]](https://i.ibb.co/c3kTzn9/Screen-Shot-2019-09-15-at-12-31-23.jpg)
Driver details:
![[Image: Screen-Shot-2019-09-15-at-12-32-26.jpg]](https://i.ibb.co/yqnGg0k/Screen-Shot-2019-09-15-at-12-32-26.jpg)
RE: Serialization of CQC SMS Serial Interface Driver - Dean Roddey - 09-15-2019
Ugh... To get rid of the warning message about unitialized fields, I set them to error state until such time as they get a value stored. But apparently the driver isn't storing values up front, and some that should be write only (and hence not affected by this) are read/write.
Let me take one more shot at it and I think we'll be OK.
RE: Serialization of CQC SMS Serial Interface Driver - Dean Roddey - 09-15-2019
OK, one more time...
RE: Serialization of CQC SMS Serial Interface Driver - gReatAutomation - 09-15-2019
Thanks.. set up another test of four consecutive SMS messages. Before each one I use WaitFieldValue to ensure SMSGateway.Busy is False before sending the message.
![[Image: Screen-Shot-2019-09-15-at-15-23-29.jpg]](https://i.ibb.co/NtkLCfL/Screen-Shot-2019-09-15-at-15-23-29.jpg)
Only the first message is sent out, then this error:
![[Image: Screen-Shot-2019-09-15-at-15-25-12.jpg]](https://i.ibb.co/qmBPkL2/Screen-Shot-2019-09-15-at-15-25-12.jpg)
I then upped the wait time to 10000 in WaitFieldValue and ran the same commands in scheduled action test so that I could see the actual number of milliseconds of wait time. The change to 10000 did the trick as I see that your changes changed the amount of wait time. Driver is busy for about 6500 milliseconds after sending a message whereas before it was about 2500 milliseconds.
RE: Serialization of CQC SMS Serial Interface Driver - Dean Roddey - 09-15-2019
Before it wasn't imposing any inter-send delay. So it would make sense it was shorter before. That's why you had to do it. Now it's imposing that. Of course one reason for WaitFieldValue() is that you can put a conservatively large time in, but won't wait any longer than is really required. So you can account for a worst case, but only ever pay for what really happens.
Oh, and another reason for the slight increase is that it's not just setting Busy back to false before returning from the SendMessage, it's doing it later during the driver's poll callback after the minimum time has expired. But the poll interval is a couple seconds. So there will also tend to be on average a couple seconds extra. I could now lower that poll interval since the stuff that the poll method does is controlled by time stamps now. So it won't do things too fast. That would let it more quickly get Busy back to false, if that would matter much.
RE: Serialization of CQC SMS Serial Interface Driver - gReatAutomation - 09-15-2019
(09-15-2019, 12:22 PM)Dean Roddey Wrote: Before it wasn't imposing any inter-send delay. So it would make sense it was shorter before. That's why you had to do it. Now it's imposing that. Of course one reason for WaitFieldValue() is that you can put a conservatively large time in, but won't wait any longer than is really required. So you can account for a worst case, but only ever pay for what really happens.
Oh, and another reason for the slight increase is that it's not just setting Busy back to false before returning from the SendMessage, it's doing it later during the driver's poll callback after the minimum time has expired. But the poll interval is a couple seconds. So there will also tend to be on average a couple seconds extra. I could now lower that poll interval since the stuff that the poll method does is controlled by time stamps now. So it won't do things too fast. That would let it more quickly get Busy back to false, if that would matter much.
Great change. Thanks. My particular CQC implementation makes heavy use of SMS.
RE: Serialization of CQC SMS Serial Interface Driver - rhamer - 09-15-2019
Hi all, I was contacted by Chris to help with this, but I don’t think I can offer much.
My only thought was to check if the AT command set supports a completed indicator of some sort.
The other (possibly dumb) idea was some form of generic async to sync driver that could generally queue action requests and feed them out sequentially.
Anyway, I am a long time out of it and I’m sure there are probably better ways these days.
Cheers
Rohan
RE: Serialization of CQC SMS Serial Interface Driver - gReatAutomation - 09-15-2019
(09-15-2019, 03:22 PM)rhamer Wrote: My only thought was to check if the AT command set supports a completed indicator of some sort.
Sending SMS is the AT+CMGS command which, after sending a message, provides response of OK after message is send
Here: https://www.diafaan.com/sms-tutorials/gsm-modem-tutorial/at-cmgs-text-mode/
And
Page 120: https://www.elecrow.com/wiki/images/2/20/SIM800_Series_AT_Command_Manual_V1.09.pdf
RE: Serialization of CQC SMS Serial Interface Driver - Dean Roddey - 09-15-2019
It could be made async queuing them up and spooling them out. It would just be tricky to implement by eye.