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:
+PBREADY
+CREG: 5,“012A”,“0124EAF5”,6
AT
AT
AT
AT
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)
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?
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.