Retries after hardware reset

[wa3off]

If the AIM4170 hardware is reset (say by cycling the ON/OFF switch), the AIM4170 PC software goes into endless retries an a subsequent scan attempt.

Monitoring the interface, it seems that the apllication might be getting upset by the initial banner that the AIM4170 unit sends when it first powers up. It looks like the software is attempting to read a mximum of 72 characters while the banner is 74 characters long. This leaves two characters unread by the software, and these show up at the front of the next response, apparently making in unrecognizable. The software sends a retry command, but since each expected response is 72 bytes, the last two bytes continue to end up at the front of the next buffer and it never recovers.

Dave, WA3OFF

[wa3off]

A further evedence that the PC software is being upset by the banner, if the serial cable is unplugged before the unit is powered back on, preventing the PC software from seeing the banner, no problem is seen.

If the PC software is not expecting any unsolicited responses from the hardware, it might be a good idea to flush the rx buffer prior to sending each command. Usually there would be nothing to flush.

Dave

[k6mhe]

Hey guys have you read the manual? On page 5 it states that the AIM must be turned on before the program is ran. Restarting the AIM (cycling power on and off) with the program running clearly violates that instruction.

Danny

[wa3off]

You are reading more into that statement that it says. It makes no reference to operation beyond initial start-up, only about operation to prevent the PC software from starting in DEMO mode.

What I'm talking about is a simple improvement to the comm-failure recovery mechanism. I've observed such retry failures under circumstances other thanpPower cycling the unit; I mentioned power cycling because it reliably triggers the behavior. I suspect that a loss of a single character in a measurement response from the AIM unit could trigger similar behavior.

Once in this mode of continuous retries it tends to get stuck there. The PC software is clearly trying to reestablish communications and it is failing to do so in an endless fashion due to, at least sometimes, to this shortcoming in the recovery mechanism. I made the suggestion so that Bob could consider a simple software change in a future version of the PC software to deal with it.

Dave, WA3OFF