| Re: [mihini-dev] SMS module |
|
Hi Marco, The porting concept is not well documented yet ;-) In (very) short you have a porting directory in the git where you can add a new subdirectory for your porting. You will need to create a new cmake target for your ‘project’. In that directory you can override files that comes from the original source tree. For instance you should be able to override messaginghal.lua with your own version where you would port the send / receive SMS functions. Here is a short extract on how to do it: Here's how to create a new default porting based on "default". It delegates all the work to "default" by including its files; as your porting become different you'll end up having to write your own makefiles · create a cmake/toolchain.foobar.cmake. In it you can put: · create a porting/foobar/CMakeLists.txt. In it you can put: · bin/build.sh -t foobar The porting mechanism was just set up recently and there are improvement still to be made, so do not expect it to work perfectly at the first try ;-) In PDU mode the message header is included in the PDU bit string (hex). I recommend that you try to send an SMS with your modem and a serial console, manually, to first check that it works. You can first try text SMS as the AT API is easier, and then try binary (PDU) mode AT API. Once you have done that, you can review messaginghal.lua, to check that it sends the right AT commands for your modem. You’ll see, once you break the ice this file is actually quite trivial ;-) Answer to your other questions: With the provided messaginghal.lua, messages are received broadcasted in Lua, and then erased from the modem. Incoming messages a recomposed ‘automatically’: if they are 7bits (aka text SMS), then the GSM alphabet will be used and the string in Lua would be the equivalent text string, if they are 8bits (aka binary, but can be text of course…), then the SMS payload is copied verbatim in the Lua string. Let me know how it goes ! Thx, Cuero De : mihini-dev-bounces@xxxxxxxxxxx [mailto:mihini-dev-bounces@xxxxxxxxxxx] De la part de Marco Descher Hy Cuero, thanks for your feedback! Currently I do not know about the "porting" concept. Could you point me to a specific info site? Unfortunately the sms code does not work insofar as that I do not get the sms message header! Is this dependent on the CNMI mode? Other questions I have: * What happens to the SMS after receive? Are they deleted from the SMS store? * Can I query what type (TEXT, BINARY) an incoming message is? Thank you very much and all the best, marco Am 09.04.2013 um 15:42 schrieb Cuero Bugot <cbugot@xxxxxxxxxxxxxxxxxx>: The prb with AT commands is that they are ‘almost’ standard, meaning that the general feeling is the same but each manufacturer will introduce its own variations. Coming back to Mihini, our idea was that the SMS specifics should be in the porting layer. That would mean that in your case the messaging.lua should be handled as a porting layer. The current messaging.lua should be seen as an implementation example of that porting. In your case it seems that you only had to change the CNMI command. That being said, we clearly need to improve the visibility on what is porting and what is not. And give examples. In the short term you modification is alright, I suggest you keep it that way until some other way is defined. I hope it’ll works for you! Thanks, Cuero De : mihini-dev-bounces@xxxxxxxxxxx [mailto:mihini-dev-bounces@xxxxxxxxxxx] De la part de Julien Vermillard Hi, Well I didn't know much this module, I'm just trying to understand the issue :) Perhaps someone involved in the SMS module code will provide more details and if it's possible to support different modes and this modem. Julien On Tue, Apr 9, 2013 at 1:47 PM, Marco Descher <mde@xxxxxx> wrote: Thank you, so what does that mean? That this device is not being supported officially by MIHINI? Or that I have to modify something else, or?! Could support for this device (which is quite popular in Austria) be included? If yes, currently the sms callback header is always nil, I receive the message though! thanks, marco Am 09.04.2013 um 13:44 schrieb Julien Vermillard <jvermillard@xxxxxxxxx>: Thanks, Looks like the supported modes are 0-2 so I think the problem is the lack of mode 3 support. Julien On Tue, Apr 9, 2013 at 1:41 PM, Marco Descher <mde@xxxxxx> wrote: Hy Julien, thanks for your answer; the respective output is: AT+CNMI=? +CNMI: (0-2),(0-3),(0,2),(0-2),(0,1) the device (once again) is: ID 12d1:1506 Huawei Technologies Co., Ltd. E398 LTE/UMTS/GSM Modem/Networkcard thanks, marco
_______________________________________________
_______________________________________________ |