Exceptions in Cellular module driver

I changed the serialPort speed to use 115200 instead of 19200. I also changed from using a loop that polls the serial port for new data and now use the serialLine.DataReceived event. It seems somewhat more stable for now.

Just setting ut up to use events instead of polling did not do the trick, so speed seems to be an issue here.

Another funny ting is, if you send uppercase OK - or any other AT commands in and SMS to the module, the driver parses part of the SMS as if it where commands from the GMS module… :whistle:

Hi,

I realise this thread is 11 months old, but did you ever get anywhere with working out if the serial line was the issue? I’m using the cellular module on a raptor, and while I can sometimes go 10 received sms’ without failure, I can then go 10 sms receives with the data being incomplete.

And it can be data missing off the end, or the odd character missing randomly in the middle of the message. I can get the number of bytes to read, read that exact amount, and see that certain data has been lost completely. For example, 50 characters sent from my mobile, 49 characters received…

I’ve even seen it where one number in the phone number gets chopped out…

I’ve tried changing drivers, changing to the DataReceived event, and changing the baud rate, but I just cannot get it stable. And yes, once something’s gone wrong, the whole module can stop receiving any sms’, either temporarily or permanently.

Any ideas would be appreciated thanks…

@ Wildginger75 - a common problem with cellular module is insufficient power. how’re you providing power?

In agreement to what Mike said, I suggest to check the power supply: it must be external with at least 1 ampere! try this.

also, which version of cellular radio driver are you using? netmf 4.2 or 4.3?
I needed to pass from 4.2 to 4.3 to improve stability.
4.2 driver has lot of “bugs” and “unhandeled exceptions”.

I would also pull the source from BitBucket as there are a few problems we identified in the latest SDK Version that John has fixed ahead of the next release.

Thanks for the replies guys.

The power source didn’t make any difference, so I concentrated on the reading of the serial port.

I added a Thread.Sleep(5) after every byte read in ReadAllFromSerial() and it seems to have done the trick, I’ve only seen one sms received that had a character missing, the rest have been spot on.

Hope this helps someone else if they have similar issues…

@ Wildginger75 - Adding a sleep to make something work is generally not a good idea unless you fully understand why the sleep is required. It might work now, but will it always work?

Fair point, and it’s something I’ll obviously keep an eye on, but to go from the majority of texts having missing data, to having one single character dropped in the last 3 days of testing is quite a remarkable change…

I got the idea from this thread:

https://www.ghielectronics.com/community/forum/topic?id=18333&page=1

He seemed to be having the same issue. Quite interesting that the same solution has “apparently” solved the problem?