BenFT01: thanks for your suggestion. Unfortunately, changing the TCP/IP packet size does not seem to make any difference for this bug.
We now have direct contact with the are sales manager for Northern Europe who is trying to get the bug resolved and also trying to get more information about what’s causing it.
Currently, the bug seems to be resolved in Open AT 7.45 beta by changing the FIFO buffer size with the command “AT+WHCFN=6,3”. Unfortunately, the Q26Ex has a chipset that does not accept 7.45 beta since it’s “unsigned”. We are therefore waiting for the manufacturer of the chipset to sign the beta release so that we can verify that it works on Q26Ex.
We are currently trying to get information on when we can have this software.
Try this on a Windows (XP) PC connected to the COM port of the module:
Go to device manager
Open the properties of the COM port you are using
Go to port settings tab and then click on Advanced
Reduce the FIFO TX size from 16 to a lower value (say 7)
Now see if you can reproduce the data loss. On my colleague’s desktop, FIFO Tx size of 16 works fine with an high speed UART (PCI) card. 7 is the value which works well on our laptops (to avoid data loss). So, try different values to see what works the best for you.
If you have see the traces on the module, look for “[data_drv_on_error] Error 0002 on UART1” which signifies UART overrun. If this error is gone from your traces, there shouldn’t be any data loss.
SPI: Thanks for your suggestion. I will try that setting once I get back to the office. But since connecting the Q26 via a demo-board to a PC is just a way to reproduce the bug, I don’t think this is a final solution even if it works. We’re using the Q26Ex in an embedded environment with an Atmel UC.
This is a problem. I spent a month looking into problems with FCM in OpenAT. There are two problems:
If you pull out a logic analyzer you’ll see when CTS asserts that last byte is lost! I reported this issue to Sierra back in October of 2009.
If you send data at 460K baud, you’ll get a watchdog reset after sending 10K+. This was also reported in October of 2009.
We wrote a sample application to show the loss of data and the watchdog crash. Sierra verified our findings. Unfortunately the response was, “This is the way it is…”. Therefore, if you have an application that needs to send a lot of data over UART you’ll have to work around these bugs until Sierra fixes it.
We then switched over to OpenUART. When we sent 10K+ data across the serial connection we would perminantly loose GPRS registration.
Hopefully, this will be fixed in the next release…