we’ve just started using the Q26 Extreme for an embedded application with an AVR microcontroller. Our goal is to communicate with the Q26 via USART1 to be able to upload information to our server. To get this working as quick as possible we downloaded the WipSoft example to the Q26. By doing this we can communicate with the Q26 via USART1 and connect to our server without any problems by just using AT-commands. So far so good. But once we start sending data we loose a byte every now and then. We figured this must be a problem with flow control between the microcontroller and the Q26, i.e. the Q26 can’t upload the data as fast as we are sending data via USART1 and therefore fills up a buffer. To avoid this, we use RTS CTS on theQ26 (AT+IFC=2,2). On the microcontroller side, we’re simply polling the CTS pin as we are writing data via USART, and once it goes high (~CTS) we stod sending data until it goes low.
For some reason this doesn’t work as expected. The pin goes high every now and then, but often it won’t go low again. It will typically stays high until the server closes the socket.
Has anyone seen this issue? Is there a problem with the WipSoft example app or any particual firmware version? Isn’t it enough to poll the CTS pin from the Q26 to avoid flooding the buffer?
We’ve now upgraded bootloader, firmware and WipSoft on the Q26, but the problem remains the same. Has anyone had a similar problem? Isn’t it sufficient to poll the CTS pin?
It seems kind of odd that no one else has had this issue. Is everyone else writing their own apps to run on the modem? It seems like a good idea to use WipSoft since it handles everything for you and let’s us focus on the task at hand instead of learning to build apps for the modem and adding another toolchain to our process.
awneil: no I haven’t. We needed a fix before a test we’re doing tomorrow, so we figured the forum would be a quicker solution. But since no one here at the forum seems to have had the same issue, the Distributor will be our next stop.
we’ve now tried both the Sierra support and our local distributor without any luck. It’s a shame Sierra has such sparse documentation for it’s otherwise very nice modules. Has anyone here at the forum had similar RTS/CTS problems? What would you recommend? Start writing our own application? Seems like a waste of time since Wipsoft has everything we need except for this bug.
After a whole lot of testing and reading we’ve now managed to avoid the situation where the Q26 sets ~CTS to high and never changes it back. I’m not quite sure what did it. However, once we got past that problem a new one arose. The q26 now seems to set ~CTS high whenever the buffer is full, but not a character earlier. This results in dataloss since a transmission of data might allready be on it’s way (in hardware buffer etc.) from our microcontroller to the q26.
The only answer we’ve been able to get from the support is that WipSoft is suppose to set ~CTS high when there is less than 64 bytes buffer space left. This does not seem to be the case since we loose data even though we stop sending as soon as ~CTS goes high.
We are seeing the same issue you are seeing related to the CTS line and flow control. I posted a question at the link below but did not get any type of response at all.