We are using the HL 8548 modem as part of a tracking unit.
We are carrying out a diagnostic on a couple of collars that have failed in the field after weeks of correct operation, this being a recurring issue at the moment.
The issue is one of non-response to AT commands after power-up.
I have attached a log file showing a GOOD start-up sequence on a new collar, collar1.txt. As can be seen the collar indicates that it is ready and we issue a sequence of commands to configure the product.
On both of the returned collars we get a BAD start-up sequence as follows:
The multiple AT commands being generated on a timeout as the modem has not responded.
The baud rate is configured correctly as we are seeing asynchronous commands from the modem but no commands are being accepted which is really strange ??
One thing I have noticed is that directly after power-up we get an asynchronous +CREG being generated by the modem, this being something we have not seen before on testing we have undertaken in the past. Has there been a recent firmware update that makes the modem register onto the network really quickly ?
Any help in relation to determining the issue would be much appreciated.
PS. We have just managed to get one of the collars to run correctly by connecting, disconnecting and connecting the battery pack a number of times. This is really strange as the modem is activated with the PWR_ON line is exactly the same way and with the same timings every time so it looks as if the modem is starting-up in correctly sometimes but not others. Can anyone explain how this can be ?
collar1.txt (651 Bytes)
How is the logfile being generated?
Note that the correct term for those is, Unsolicited Responses.
We have a unit hooked up to a debug port, and we are taking the feed from there.
Still not quite clear:
Do you have a separate piece of kit directly monitoring the hardware connection between your host and the HL8548, or is it some software function within the host itself logging what it thinks it sent to the HL8548, and what it thinks it saw from the HL8548?
We have a separate bit of kit directly monitoring the connection, this is actually going on.
Both contain the unsolicited +CREG - so that’s not a problem in itself.
Can you get timestamped logs - to see if the timing of the unsolicited +CREG is significant … ?
In the “successful” log, this is odd:
seems to be a collision of the OK response from the CMGD with the next AT … ?
IS your code properly synchronised to ensure that it’s had the Terminal response to one command before sending the next command?
Just to say we are not trying to get a new application running. This is an existing product that is experiencing issues in the field so the communication interface side of things is tried and tested.
We monitor the serial communication lines between the modem and the microcontroller directly and there is the occasional time where an AT command my send a supplemental OK response after its command response that may cause the odd character to be mixed up in the log but this does not affect the operation of the modem or have any relevance to the issue we are experiencing.
Ah, the good ol’ Proven Product Syndrome.
I’m sure we’ve all had the experience of chasing down a mysterious bug and, when the cause is finally located, thought “how did this ever work?”
It can be hard enough to track these things down with full access to & details of the system - let alone remotely as a stranger.
You seem to be taking the right sort of approach - I can’t think of anything else obvious to suggest.