We are replacing GR64’s by Q64 using the compatibility plugin. So far, only
major differences noted were power-on/off sequence and “ATO” (get back to
online) extra “OK” string answered.
But after AT*E2IPO is executed, we are facing something that seems a buffer
manipulation problem on either the plug-in or on Q64 itself.
Basically, we have something from 24 to 400 bytes to transmit (uplink). If we
do all at once (say, all bytes within the time-window requested by the E2IPS) it
seems to work fine.
If, in the other hand, we send bytes on variable chunks (say, 10-10-40-40-60 bytes, of a 160 bytes total),
and we do it fast (1ms or less between chunks written to the serial port), some bytes are somehow “hanging” into Q64 memory and
either takes too long to reach the server or never get’s there at all.
Funny thing is that with our “debug on” feature (that creates some delays between written chunks), solves the problem.
To sort things out, we disable our debug feature but added a 20ms sleep between chunks (this makes
our application to generate smaller number of chunks and bigger ones) and the modem performs ok.
We have monitored flow-control lines: they are not entering scene (packages are small).
We have tested all “GR” members against the Q64 and we have noticed this only in the Q64 processor.
Our plugin is “gcc_Q64Soft_256KB.wpb.dwl”
Have anyone experienced this?