Hi,

On Mon, Oct 19, 2015 at 09:20:41PM +0200, Matthieu Gaillet wrote:
> Sure. Good luck to use this crappy website… 
> http://www.mianfeiwendang.com/doc/c2fdadc6a878f5c1871f2fff/1 
> <http://www.mianfeiwendang.com/doc/c2fdadc6a878f5c1871f2fff/1> 

Thanks!

 
> > The individual flags in bytes 0-12 (RS232, Auto, DC, etc.) are exactly
> > the same as in the FS9721, though apparently the order is inverted (bits
> > 3..0 instead of 0..3), assuming that's not just a typo in either our wiki
> > or the table above.
> 
> Right. I double checked and I’m pretty sure this table is the right one (I 
> wrote it based on the data sheet and my own observations). 

Yup, looks correct for this chip (see below, Peaktech 3415 protocol).

 
> > http://sigrok.org/wiki/Multimeter_ICs#Fortune_Semiconductor_FS9721_LP3
> > 
> > The LCD digit mapping might be different. Can you put the above table and
> > the digit-mapping in the wiki please (similar to the FS9721 docs above).
> > Oh, and an "lsusb -v" as well.
> 
> I think the author of the wiki for the FS9721_LP3 entry used a "non-standard" 
> way of naming each segment of the display. Looking at the data sheets, the 
> protocol is the same, except the nibble order.

There is no "standard" way for segment naming as far as I'm aware, it's
just a bunch of random letters that match up to some segments. The
FS9721 datasheet seems to call them a1-a7, b1-b7, ... and pX (for the decimal
point segment), but that's not standardized anywhere either. Meither is
the order or anything else, I think.


> Bus 029 Device 002: ID 067b:2303 Prolific Technology, Inc. USB-Serial 
> Controller 
> 
> Looks like a good old Prolific 2303 Serial to USB cable.

OK, thanks. Please put the full "lsusb -v" on the wiki page nonetheless.

 
> > The length of 15 bytes (instead of the FS9721's 14 bytes) is also
> > interesting, they probably just needed a few more flags and ran out
> > of space in the 14 existing bytes.
> > 
> I agree, though there seems to exist an option (setting in EEPROM) to send 
> the data in 14-byte form, if I correctly understood the chinese translation.

Interesting. Please try to figure out the exact protocol bits / meaning
for that mode as well then (and document it in the wiki), if possible.

Chances are that simply the last byte will be omitted, but who knows...

 
> > Then you'd just add one DMM() entry there for the Velleman DVM4100
> > referencing the parser etc.
> 
> ... and to the Peaktech 3415 USB which looks rigorously like the same 
> machine. 
> http://www.peaktech.de/productdetail/kategorie/digital---handmultimeter/produkt/peaktech-3415-usb.815.html
>  
> <http://www.peaktech.de/productdetail/kategorie/digital---handmultimeter/produkt/peaktech-3415-usb.815.html>

Looks alone don't have to mean much, but in this case I think you're
right. It seems to use the same protocol (and possibly also the same IC).

The download here
http://www.peaktech.de/productdetail/kategorie/digital---handmultimeter/produkt/peaktech-3415-usb.815.html?file=tl_files/Software/PeakTech_DMM%20Tool_ISO_complete_18082015.rar
contains a file named "PeakTech device communication protocols
2015-07-20.pdf" which describes the Peaktech 3415 USB protocol
(among other Peaktech protocols, which is neat).

And the protocol seems to match quite well. Some notes:

Byte 13 has "ADP2 (always 0)", "ADP1 (always 0)", which indicates that
these bits might be wired differently for other DMMs with the same IC, i.e.
their meaning could be different for other DMMs. These should then
be handled by the mechanism we use for fs9721 and others as well, e.g.
sr_fs9721_10_temp_c() etc. so it can be configured properly per-DMM.

Byte 14, bit 0 is "APO", i.e. Automatic Power Off of the device (after a
few minutes or so).


So yeah, making a new DMM parser (similar to the fs9721 one) is the
proper thing to do in this case.


Cheers, Uwe.
-- 
http://hermann-uwe.de | http://randomprojects.org | http://sigrok.org

------------------------------------------------------------------------------
_______________________________________________
sigrok-devel mailing list
sigrok-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sigrok-devel

Reply via email to