Hello,
I have included a screen shot of what I am seeing on the HDQ interface to our battery.
First, note that I am showing a data trace at my Open-Drain TX buffer and I am showing one at the battery connection (to prove this signal is getting off my board and to the battery). At one point I was showing my TX signal and my RX signal to show the feedback was getting to my RX buffer and that I was receiving data (I have since move that connection out to the battery to prove the signal is getting to the battery). That is why there are two signals on the screen shot for a 1-Wire Interface.
Next, I am trying to show a ‘1’ being sent and a ‘0’ being sent. Note: All bit cycles are 200usec long and for the ‘1’ I was using 20usec LOW but have since change that to 40usec LOW and 160usec HIGH and for the ‘0’ I send 120usec LOW followed by 80usec HIGH.
When ever I send data I also receive data and in my code all my TX data (bytes) matches my RX data (bytes).
Not shown on the screen is a LOW pulse of 250usec to ‘sync’ the initial battery data (recommended by the battery manufacture). That LOW 250usec pulse was about 2msec before the start of actual data to the battery.
I send a control byte to the battery (0x01) followed by several ‘0xFF’s to try and receive data from the battery.
When I first used the 20usec LOW pulse to the battery I would never received any response from the battery, but when I widened that LOW pulse on the ‘1’ from 20usec to 40usec, I started receiving some response from the battery but it was not a consistent response (usually one response in about 4 or 5 command packets).
Any help would be appreciated. Thanks!
What fuel gauge IC are you trying to communicate with inside the battery? It's always a good idea to include the device name in your post title so it will get to the right person.
Thanks,
The only reason I left that out is that we aren't manufacturing the battery. The battery is spec'd such that the interface must be "BQ2060-like". So, there might be more than one battery vendor, and as long as they are using HDQ, they may or may not be using the BQ2060. However, for this discussion, we can assume as much.
David,
Just wanted to check in to see how debugging this issue is going.
Your input is greatly appreciated!
Best regards,
Austin Miller
Digital Field Applications
If my reply answers your question please click on the green button "Verify Answer".
Jamaal,
The bq2060A uses SMBus (two-wire like I2C). If you are using a single-wire protocol then it must be some other device in the pack. Are you sure this is HDQ? Or could it be SDQ/1-Wire?
It might be a good idea to crack open a pack and see what IC is really in there.
Hi Jamaal,
The bq2060A does offer the HDQ interface but it would be interesting if this is actually a bq2060A. The HDQ interface is open for use by others without TI's consent so could be uC which may show this kind of issue. We have had no issues with the HDQ on the bq2060A like the one you describe.
Best regards
Garry