What started off as a little exploration led me deeper to try and better understand what was going on with the Keweisi KWS-V20 USB Tester. Even though I don’t have any specialist bus sniffing gear, I decided to just wing it with the Serial Decoding features of the Picoscope 2205A and see what I could get.
As usual, the disclaimer applies – I can’t guarantee this is all correct, and can’t be held responsible if you damage anything through attempting to use what is written here.
Tapping In
The first step was to try and get a good connection to the buses in question. As there were two buses in question, a total of five connections were made to the IC including ground.
The connections aren’t pretty by any measure, and the mixture of lead and lead-free solder creates the frosted brittle-looking joints that function well enough. After all, this only had to last long enough for me to see what was going on.
Serial Decoding
I decided to start by taking a look at the LCD bus in more detail, as it was the one with a constant stream of data.
The first thing I realized is that the LCD bus data “bursts” once every 4ms, or a frequency of about 250Hz. This now explains the “CLOCK?” signal I saw – this is not I2C (as pointed out by a reader in the previous article merely hours before I got to writing up this one). This is in fact SPI, and the CLOCK? signal is the slave select line, activating in synchronism with the bursts of data. There may also be an explanation for pin #14 which appears unconnected – maybe it’s the matching hardware MISO pin, as most SPI drivers have four connections, and the LCD doesn’t really need to talk back to the host at all.
Looking closer at one of the bursts, it seems that the bus frequency is about 263khz, and a total of 18 bytes (or 144 bits) are sent. Because of the way the bursts start and stop, there wasn’t an easy way to trigger it reliably with the oscilloscope especially as there was no way I could think of to properly configure it to avoid triggering “mid-stream” on a downward clock transition. As a result, I decided to trigger once the signal exits the window for a specified amount of time – basically triggering after the end of the burst and “ignoring” the idle time between bursts. This sort-of-worked, with the exception that it was slow and missed many updates, and due to the “jitter” in the trigger, the data jumped around a bit but at least the issue of “fragmented” data was solved.
Leaving it for a while, I managed to get the following bytes of data, deduplicated:
Because I couldn’t exercise the display and have all values varying, some of the bytes listed as static may actually not be static at all. I couldn’t see any easy correlation between the values and the data – maybe the values sniffed are inverted, maybe they are bit-mapped to segments and packed together.
That got me thinking – just how many segments are there on the display? I took a photo of its brief “reset” test and counted …
In many cases, the symbols for V, A, T and mAh are single segments that are fixed to stay on and are not really “segments”. Likewise, the colon is likely a single segment rather than two. The numbers listed are being as generous as possible, and tallying them up, I arrive at 116 segments. However, it’s more likely to be 109 segments based on the above reasoning.
If the display was bit-mapped, 15 bytes would be enough for 120 segments. As a result, there’s probably a little over 3 bytes of data used for other purposes – possibly configuration of LCD drive parameters (e.g. contrast), segments which don’t exist in this particular panel, or timing. It’s still relatively close to the number of segments, so I expect the data to be bit-mapped to a segment in some way. I just don’t have the inclination to decompose all the bits and work out which is which, but I suppose if one were really interested, they could desolder the IC and then try talking to the display directly feeding different bytes to see how it liked it.
Time to divert our attention to the I2C EEPROM communications. The first thing I did was to try and ascertain what happened whenever the unit stored updated values to the EEPROM.
It was found that the I2C bus operated about 147khz, so around “standard” rate but a little faster. Whenever 30 seconds would pass and the unit was integrating, a burst of bus activity occurred with some wait between each burst to allow time for chip processing. Because the Picoscope did not reliably capture every burst, I let it sit around for a while and filtered out any duplicate accesses to addresses. The resulting data appears as follows:
It seems to be a classical EEPROM write to addresses 0x00 through 0x04 (5 bytes). By checking with the display after an hour of time, I confirmed that address 0x03 contains the decimal hours, and 0x04 contains the decimal minutes. Because of this, I expected addresses 0x00, 0x01 and 0x02 to store a pair of digits each for the integrated mAh. Contrary to expectations, this didn’t seem to be the case – the value for 0x00 was seen to use raw unsigned binary storage of the mAh value – having a value of 0xAE at the end to signify 174mAh. As a result, I believe the three bytes 0x00, 0x01, 0x02 form a 24-bit storage for the integrated mAh value even though I haven’t seen any data stored in 0x01 and 0x02 during the short testing (as the integrated mAh value wasn’t high enough).
When the device is plugged in, it needs to restore the data from the EEPROM to the display. This gives us a good chance to witness exactly what is being read out.
As expected, the read-out checks the data in addresses 0x00 to 0x04, a total of five bytes. Based on this analysis so far, no wear levelling is employed and even though the EEPROM has storage for 256 bytes, only the first few are used. Based on a 1 million cycle endurance and a 30 second timer, the EEPROM is expected to expire at about 347 days of continuous operation. Sadly, no additional data seems to be stored or restored.
However, when it came to clearing the EEPROM, there was a curious quirk:
The routine appears to clear six bytes, including address 0x05. But I haven’t actually seen this address being used. Coding bug perhaps?
As a result, I now believe that the chip connections are as follows:
Conclusion
Sometimes I like putting posts up as I go, and this was one of the cases of that. As a result, the last post did have some loose ends which weren’t tied up. Initially, I didn’t really feel like exploring it, but then, I had a change of heart and decided to just try it anyway. At least, now I know a little more about this device … although it’s probably not data that’s really useful to me right now, it was worth the try just to learn more about snooping about on buses and getting the scope set-up right to capture and decode the data.
Hi Gough,
I like your style. There is not enough people out there reversing the stuff that you find on ebay, and some of it gives a good insight into how cheap something can be made (what corners they cut).
Being a USB device, I’m always concerned about “extras” that are included when you buy something from ebay (I’ve seen memory sticks with factory included viruses). I’ve not pulled this meter down to see, but are the USB connections ‘free’ (probably), do they just pipe though (nice if they did), or are they connected internally (very unlikely)?
Cheers mate!
Owen (Australia)
Dear Owen,
Unfortunately, as the PCB is black and fairly well populated, it’s pretty hard to get a visual guarantee on the USB data-line connectivity. I, too, have received USB devices with “pre-loaded” viruses, and have heard of certain chargers and e-cigarettes which have been infection vectors, so the concern is quite valid. However, I do believe this device is “legitimate” and the connections are straight-through. The reason I say this is due to the following:
– Device plugged in with nothing on the downstream port results in no new devices attached to the USB bus (checked using lsusb in Linux which should be pretty reliable there)
– Device plugged in with a USB storage device connected on the downstream port results in the storage device being detected and usable (thus the device does not appear to interfere with communications).
– Continuity test of D+ to D+ and D- to D- pins gives me 0.6ohms for both, where the leads shorted is 0.6ohms, so thus it’s likely the pins are connected straight through.
– Continuity test across D+ and D- in either direction gives me no continuity, so it’s not likely anything is connected across the pins.
That being said, for the paranoid, it cannot be guaranteed that there isn’t something else going on (e.g. a tap somewhere, another route of “exfiltration”), but I would bet my bottom dollar that it’s extremely unlikely to downright impossible because of the price and power consumption of the meter alone.
Hope this helps.
– Gough
Hi Gough,
This is awesome! Thanks for posting this. I’m came across your blog while searching for a cost-effective method for logging Voltage, Amps, and power consumption of various USB powered devices, mainly Single Board Computers like the Raspberry Pi.
Did you figure out if its possible to use the Keweisi KWS-V29 for data logging to a PC / RPi ?
I also read your post on the accuracy of Charger Doctor and USB detector, does the this have similar accuracy characteristics or is it better or worse?
Best,
Sri
Hi Gough,
This is awesome! Thanks for posting this. I’m came across your blog while searching for a cost-effective method for logging Voltage, Amps, and power consumption of various USB powered devices, mainly Single Board Computers like the Raspberry Pi.
It seems possible to attach wires to the LCD SPI lines of the IC and connect to a RPi/Arduino to demodulate and log V and A. Would attaching wires to these lines significantly impact or modify the signal?
From your post on the accuracy of Charger Doctor and reading your review on the Keweisi KWS-V-20, it looks like the V20 has slightly worse accuracy: ~1% on voltage and ~3% on amperage. Which would your recommend, does the Charger Doctor have a similar method of logging data?
Perhaps its also possible to ‘calibrate’ the meter in software using a bench power supply, whether it will remain accurate over time remains to be tested.
Best,
Sri
Sorry, I’m not at home and haven’t been over the past few days, so haven’t had a chance to reply.
On the whole, I’d have to say modifying such a device is probably not worth the hassle given that on an Arduino, you could do it using its onboard ADCs and an outboard opamp if necessary, and achieve better behaviour in regards to small signals and read-out frequency. If you really must modify the devices, you could probably come up with your own set-up but you’re now at the whim of the manufacturers who may change things at the drop of the hat. Ideally, the impact on the signals isn’t big, and that is because inputs are usually fairly high impedance. Otherwise, you could buffer it through an opamp configured as a voltage follower. Still, not an ideal situation by any means, as you would then have to determine the bit-mapping of the message to the LCD segment, and then decode based on the LCD segments lit, what the actual values of interest is.
The accuracy issue is not unexpected. Cheap ADCs are just like that. I don’t have any particular recommendations, so as to say, this one has integrated mAh display and the others that I tested didn’t. The Charger Doctor’s 7-segment display is more traditional and maybe decoding that (or using a camera and OCR) is possibly easier although it does require more connections to sample it.
You could probably calibrate it, but the temperature and voltage of the supply might affect the cheap ADC it uses internally, and the resistance itself would have a temperature co-efficient as well. They might also age and drift in the case of cheap or poor components, so it’s really more effort than it’s worth in my opinion.
The only reason I bother putting it up is really to say “how much can I trust the readings?” as in what the potential margin of error may be, as knowing the limitations in your test devices is a good deal of being able to use and interpret their results effectively.
– Gough
lui_gough , i got one of these Keweisi units, but it differs from yours (and any other i’ve seen online).
The back part of the board does not have a blob! It has a lot more of smd components too.
It says KEWEISI Version 3.1 in the board surface. Also, the plastic latches are on the inside, so open it up is really hard (without breaking something).
Im curious as if this unit also supports high voltages.
If you are interested, i will try to open it, and take some pics.
Would be nice to find out what MCU is that.
Hi, i was using this for a long time and i was very happy, Suddenly display is off but there is output voltage. I am trying to find out lcd power supply to meassure ,which pins are for display?
Your info is really helpuff!! i found vdo 3.3 (HT30) is burned. I sent 3.3 volt from another power supply to the output and dispaly is working !! tnxxx
I was wondering if we could re-program the MCU to introduce wear leveling & write some code to measure untouched space in the chip (as diff capacity eeproms maybe used) & register majority of the remaining space as spare sectors.