Thursday, July 13 2006, 02:42
Junghanns.net quad GSM PCI arrived!
By fake - Permalink
oh, what nice day: the Junghanns.net quad GSM PCI arrived!
No, i'm not swimming in money, my company bought it, not me personally ;) It's ~ 2k EUR, a little expensive for a toy - but worth it's money in a production environment (or so i hope - time will tell).
The moment i heard the package arrived at the office, i went to the mobile phone store right around the corner of where i live and asked for a GSM antenna - ha, ha, like they sell those. "Damn!" i thought, knowing that running the device without an antenna will most likely not work, and may even break it. So i went to the office without a GSM antenna, and opened up the box:


Tadaa! 4 small, but sufficient antennas were included in the package! The card is robust and well-manufactured, the SIM card holders are on the back, the topmost one being connected to the topmost antenna connector, as can be seen in the jumper settings sheet.
For the ztgsm module to work, you'll need a bristuffed asterisk, forget about the stable 0.2 branch (it's asterisk 1.0, yuck!), get the latest version of 0.3 instead, it's asterisk 1.2.9.1 and zaptel 1.2.6, so it's up-to-date. It's a little uncomfortable to be forced to switch to the bristuffed asterisk, but maybe the ztgsm driver will find it's way into mainline zaptel. Trying to use the ztgsm with mainline asterisk and zaptel failed for me because of a missing libgsm-like library inlcuded in bristuff... ztcfg already failed to load it's configuration.
once ./install.sh of bristuff finished, copy over the ztgsm/zaptel.conf.unoGSM, ztgsm/zaptel.conf.duoGSM or ztgsm/zaptel.conf.quadGSM to /etc/zaptel.conf (assuming you didn't already have device configs in there, then just append them, of course...), depending on which model you own. If you have multiple GSM card with only part of the sims installed, you don't need to alter the settings here, you can do that in zapata.conf, which is also located in ztgsm, again in the zapata.conf.unoGSM, zapata.conf.duoGSM and zapata.conf.quadGSM versions. Copy the according one to /etc/asterisk/zapata.conf (again, don't overwrite if you already configured a Zap device, stupid!) and edit the file. Enable as many sections as you have sim cards installed for (or less ;), assuming you installed them from slot A-D in row - I didn't test other configurations, it's pretty time-consuming un-screwing all the antennas to get the PCI card out again to swap sim cards, you know, and it's very dusty down there under my desk... oh well, back on topic. Make sure the pin codes are correct...
With /etc/zaptel.conf and /etc/asterisk/zapata.conf configured, it's time to modprobe ztgsm. this took about 30 - 40 seconds here...
ztgsm: iomem at d5204000 size 8192 ztgsm: ioport size 256 ztgsm: Junghanns.NET quadGSM card configured at io port a000 IRQ 17 io mem f8ae8000 HZ 250 CardID 0 ztgsm: Powering up all spans... done. ztgsm: VERSION aa32 ztgsm: 1 multiGSM card(s) in this box, 4 GSM spans total.
the leds on the rear of the card finally light up and show some of their colors! then, ztcfg -v and asterisk -vvvvvvvc. If you entered a wrong PIN code in zapata.conf, you will pay for your education now. On the console you should note some debug messages about the GSM spans connecting to the network. If you now issue a Dial(Zap/(#channelr from zapata.conf)/012345) the device should call the phone nr.
In my case, though, it said it "unregistered from the network" instead, and i heard a blipblipblip sound on the snom phone i placed the call with - after call termination, the following error was displayed:
chan_zap.c: GSM: 1 !+CME ERROR: operation not allowed!
Oh jesus, i thought, how am i going to debug this? After some digging and googling for the CME Error codes, i found out that the answer is easy: screw out the card again, and insert the SIM card into a usual cellphone. voila - the card was not valid anymore, because someone at my company re-ordered the same card and didn't tell me. "Network registration failed" was what the Nokia cellphone told me after it accepted the PIN code. So i tried another SIM card, and dialing out and in worked!
Unfortunately it's not possible to suffix extensions to the telephone number on gsm calls, so it seems you'll always have to use either the "s" extension or the individual telephone number of the SIM card recieving the call on incoming calls in the from-gsm context (if you left the default in zapata.conf, that is).
I'm still a bit puzzled about how smsq, the queuing tool for app_sms works, but i'll figure that out once i have the correct SIM card.
13 comments
Hi,
I have the bristuff version of Asterisk up and running with a Junghanns "duo GSM PCI" card. (Well, more or less...I still haven't taught it to play nice with my TDM400P, so I can only load one of the cards at a time...but that's neither here nor there.)
Anyway, GSM voice works great, but I'm looking for a way to send and receive SMs via the same card. (It sounds like you are, too!) In fact, I would be okay using kannel or alamin or some other linux SMS gateway application, if I knew how to talk to the Junghanns outside of Asterisk. (I assume this would require a different driver...with some kind of serial-device emulation?)
At the moment, my Asterisk console will tell me when the channel receives an SM, but it all it does is say...
"SMS received on span 1. PDU: <number>"
...and I'm hoping I don't have to go hack the GSM_EVENT_SM_RECEIVED case of the handle_gsm_event() method of the chan_zap.c patch. *gulp*
As for sending messages...I haven't the foggiest notion where to begin. I think I have a fairly good sense of how app_sms works, but it's all about using the PSTN to talk to an SMSC middleman, right? Does it have a hidden feature for cutting out the SMSC middleman? Does smsq have a hidden feature for cutting out the app_sms middleman? Can I convince either of them that I _am_ the middleman...?
Thanks!
-Chris
Okay,
So I now see how to use Asterisk to send via the Junghanns GSM card ('asterisk -rx "gsm send sms <channel> <destination> <message>'), but I'm still not sure how to capture SMs in a useful way. It would be nice to at least dump messages (even as PDU strings) into a log somewhere.
I'm pretty new to Asterisk, so I'm not sure if this is currently possible through some kind of...I don't know...custom verbosity level that logs messages from a given module. Or something....
Thoughts?
Thanks,
-Chris
dude, you rock. where did you find out about the gsm send sms command? i'll look into the sms recieving now...
hm, this is odd. when i reply to the message sent as you stated above, the
asterisk console prints:
-- SMS received on span 1. PDU:
XXXX34660405F1240C91346684XXXX1100006070721202248004D4F2XXXX
but no dialplan actions are taken, and i can't find the sms anywhere on
the asterisk box :(
the X's were numbers, too, removed for privacy.
Yeah,
The documentation for this thing is a bit...sparse. :)
> where did you find out about the gsm send
> sms command?
I sent the thing an SM, just to see what would happen, and then googled for that "--SMS received..." string, which turned up the text of a CVS commit. Once I started digging inside the bristuff-patched version of chan_zap.c, I noticed that there were a few other "gsm" commands, one of which was a method for sending. *shrug*
In other words, I got lucky.
I had never heard of a PDU before, but apparently that's the entire SM? In some gawdawful encoding scheme? I was hoping the text (or the PDU) would get dumped somewhere, as well...but it didn't. And, looking at the code, there's nothing else in that function. The console message is the only action taken upon receipt of an SM.
Seems to me, our options are:
(1) hack chan_zap.c
(2) find a verbosity level at which the PDU will at least be written to a log file or something...which would allow us to parse it outside of Asterisk.
As for sending...here's a stupid Asterisk question. How do you access a CLI command from a dialplan? It seems a bit goofy to create a script that calls 'asterisk -rx "gsm send sms <foo> <bar> <baz>"' and then call it from Asterisk through AGI. :) But that's exactly what I'm about to do....
Yours,
-Chris
Heythere,
Any progress? I hacked chan_zap.c to make it write that PDU message to a log file, which I scrape into a MySQL table using a cron'd perl script. Fugly, but it works. The hardest part was the CPAN kungfu required to get GSM::SMS::PDU installed so that I could parse the PDUs....
Anyway, In order to _send_ an SM, from a dial plan, I'm doing something even uglier. It all kind of makes one wish for a VoiSmart vGSM card instead....
My biggest problem now is the fact that I can't get the Junghanns card to coexist with my TDM400P. They both work, but if I try to load both modules, I get errors when asterisk starts up, and when attempting to use the channels. Are there channel numbering restrictions that I'm not aware of? Do they have to be in some order? Do I have to load the modules in a certain order? *shrug*
Yours,
-Chris
I am having similar problems here with the hardware. I have a unoGSM that does not like the Digium TDM imn the same box. Documentation: what can i say :) it does not exist AFAIK.
I trying to get this hardware documented, i will love to get your patch for SMS handling and some examples how to send SMS both from extensions/dialplan and interactively.
Is there any debugging information possible from the Motorola module? Signal strengh will be great to get out of the PCI card.
Im not sure, if your still interested in that topic, but I just found out, that with the latest bristuff package (0.3.0-PRE-1x (* 1.2.14)) it is possible to use the managerAPI to send SMS as simple as:
Action: Message
Channel: Zap/yourGSMcardgroup_or_chan/recip_cell_nr
Message: This is the message.
Also you can put a callfile in /var/spool/asterisk/outgoing
containing
Channel: Zap/yourGSMcardgroup_or_chan/recip_cell_nr
Message: This is the message.
:)
greets
SCM
of course i am, thanks a lot!!
did you dig the source to find this out, or this there some source of information i haven't found yet ? ;-)
How reliable are you finding the sms functionality? I'm having real problems where every few sms messages fails with this error:
WARNING[27185]: chan_zap.c:8602 zt_gsm_error: GSM 13: Cannot send SM when in state 15
The error can occur if I try to send sms to the card too fast - that's fine, I just put a 5 second delay between eash message.
However it also happens randomly for no apparent reason. When this happens the card is stuck in "state 15" (whatever that means) and no more sms can be sent.
The only way to clear the error then seems to be receiving a voice call.
I just bought a used unoGSM card for $50CAD from my company and I am trying to get it to work. I downloaded the bristuff-0.3.0-PRE-1y-j and ran the ./install.sh. After install I did the /etc/zaptel.conf and /etc/asterisk/zapata.conf by copying the ztgsm/zaptel.conf.unoGSM to both /etc/zaptel.conf and /etc/asterisk/zapata.conf. then when I do modprobe ztgsm I get FATAL: Module ztgsm not found
Any help would be greatly appreciated!
Well drbob, you probably executed the install script and didn't notice compilation errors on the ztgsm module. This is very common since the script will keep going even if some compilation errors showw up.
since all the files are patched already with the first execution of install.sh...execute ./compile.sh instead.
Carefully read the output, and you will certainly see the errors.
Try to do the following:
1) Download and install the linux-source-[version] package for your system.
2) create a symbolic link to the kernel sources (not headers) called linux-2.6 in /usr/src/. After doing this a directory /usr/src/linux-2.6 should exist and should be pointing to your kernel sources.
re run the ./compile.sh script. It should build the modules without any problems.
I'm having problems myself with this tech... i manage to patch the brisstuffed version of Zaptel with the sangoma's wanpipe drivers and both cards (FXO and GSM) are recognized by my box.
Now... the problem is the state of the channel... asterisk keeps telling me Cannot send SM while in state = 18.
If i do a gsm debug channel XX, then followed by the action, i will get GSM XX: state = 18.
Anybody knows what state 18 means??
Regards
Pedro GUillem
CTO - Fabrica de Credito (Bogota- Colombia)
I have a few VGSM cards from Voismart. Claimed 100% compatibility with Asterisk was never achieved because software drivers contain a number of bugs which Voismart is not interested to eliminate. Compatibility with Linux kernel is not straightforward either. Technical support in Voismart when asked to help with some software issues works in such a way: first you are offered to change a PCI slot, then change kernel version, then you are offered to send your card to Voismart and if found functional, they would sell you a newer card for half a price. But how can their customers be sure that same story would not continue with a newer versions of VGSM cards?
With my more than 3 year experience with VGSM cards from Voismart I can conclude that cards are not suitable for working in a production environment.