Hi there, So after my discoveries (see below) and with help from Uwe (thanks !), I succeeded creating a new parser for the DTM0660. You can find the code on my Github pull request <https://github.com/pagaille/libsigrok/pull/1/files>.
I already added an entry for the PeakTech 3415 since its documentation states clearly that they use the same protocol version than the DVM4100. However, this should be confirmed. I also edited the wiki and added those pages : http://sigrok.org/wiki/Velleman_DVM4100 <http://sigrok.org/wiki/Velleman_DVM4100> http://sigrok.org/wiki/Multimeter_ICs#Dream_Tech_International_Ltd_DTM0660 <http://sigrok.org/wiki/Multimeter_ICs#Dream_Tech_International_Ltd_DTM0660> Please note that the DTM0660 is able to fully reproduce <http://sigrok.org/wimg/3/34/DTM0660_protocol_options.png> the usual Fortune Semiconductor FS9721_LP3 <http://sigrok.org/wiki/Multimeter_ICs#Fortune_Semiconductor_FS9721_LP3> 14-bytes protocol. This may suggest that this IC is actually more prominent than first thought. Have a nice evening, Matthieu > On 21 Oct 2015, at 02:03, Carl-Fredrik Sundström <audio...@gmail.com> wrote: > > > 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 > > <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 > <mailto: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> > > <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 > > > <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> > > > > <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 > > <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://hermann-uwe.de/> | http://randomprojects.org > <http://randomprojects.org/> | http://sigrok.org <http://sigrok.org/> > > ------------------------------------------------------------------------------ > _______________________________________________ > sigrok-devel mailing list > sigrok-devel@lists.sourceforge.net <mailto:sigrok-devel@lists.sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/sigrok-devel > <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
