There is a standard for 7 segment display segment naming, Dave Jones talked about it on one of his recent videos.
https://upload.wikimedia.org/wikipedia/commons/thumb/0/02/7_segment_display_labeled.svg/150px-7_segment_display_labeled.svg.png On Tue, Oct 20, 2015 at 4:34 PM, Uwe Hermann <u...@hermann-uwe.de> wrote: > 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 >
------------------------------------------------------------------------------
_______________________________________________ sigrok-devel mailing list sigrok-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sigrok-devel
