[Owfs-developers] Support for the DS2438 and the DS2436
Hello! New project time here. I'm busy trying to come up with something that will harness the amazing collection of parts here and I've got a batch of DS2436s that I want to apply, one of them certainly. Or the DS2438. I've got a batch of them as well. So I'm wondering. Am I correct in my belief that support for these parts is still included in our code series? - Gregg C Levine gregg.drw...@gmail.com This signature fought the Time Wars, time and again. -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Support for the DS2438 and the DS2436
The DS2438 is certainly supported and used in any number of devices (humidity sensors, multifunction sensors from HobbyBoards and iButtonlink among others). he DS2436 is supported based on it's datasheet, but I can't recall if it's been tested in real life. The command set is similar to the DS2438 so should work well. On Sun, Jun 22, 2014 at 4:25 AM, Gregg Levine gregg.drw...@gmail.com wrote: Hello! New project time here. I'm busy trying to come up with something that will harness the amazing collection of parts here and I've got a batch of DS2436s that I want to apply, one of them certainly. Or the DS2438. I've got a batch of them as well. So I'm wondering. Am I correct in my belief that support for these parts is still included in our code series? - Gregg C Levine gregg.drw...@gmail.com This signature fought the Time Wars, time and again. -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
[Owfs-developers] Support for LinkUSB via libftdi
Hi, I've previously mentioned my work on LinkUSB performance improvements [1], and my goal to write a libftdi based implementation. The client-timings are generally cut about 2.5 times, depending on operation. A temp sensor is read in ~50ms instead of ~123ms. I now have some code which works fine, I'm running this with my LinkUSB 1.5 on FreeBSD 9.2, performing temperature readings of 24 mixed temperature sensors, and 4 DS2406's. The temperature is read every 30 seconds, and I (try to) scan for alarm ever 0.3 seconds. In other words, pretty heavy load. This has been running for a few days without any problems now. -(TL;DR below)- Some background (partly recap from earlier thread, but some new facts, and also repeating here to keep it gathered): This might be seen as micro-optimization, not really useful if you have a small net with few sensors. However, with a couple of DS2406's wired as inputs, I want as low reaction time as possible. This is quite a big step towards that goal. Other optimizations I'm doing is of course simultaneous conversions and using alarms etc, but that's another story. It all started with the random outages I wrote about in the other thread, in which I got some tips on the LinkUSB's different baudmodes. While looking into this, I also noticed that my DS2480B-based lab net performed much faster than the LinkUSB-based net. After some digging I found a few areas which could be improved. It boils down to mainly two things: * The FTDI FT232R (USB-RS232) chip which the LinkUSB utilizes, does not perform well with low amounts of data. The 64byte data buffer is by default flushed every 16ms, or when full. Most OWFS operations does not produce those amounts of data, so every transaction was delayed up to 16ms. This has been mitigated by changing the FTDi chip timer to 1ms, and this is also the main reason libftdi is used. (FTDI docs calls this the latency timer) * The LinkUSB operated at 9600bps by default. Every sent byte on the 1-wire bus is transmitted hex encoded, so 2 bytes is used for every single wire-byte. The DS2480B uses raw bytes, thus the LinkUSB yielded half the speed. This has been mitigated by using 19200bps instead of 9600bps. Higher speed (38400) is not usable, since it overruns the 1-Wire bus unless we take special care of rate-limiting. Could maybe be used to speed up the search functionality.. A third thing I made some experiments on was the fact that OFWS jumps in and out of byte mode. However, trying to setting this mode explicitly and going in/out from it only when it was actually required, yielded worse timings in the end (with the above fixes applied).. Most likely since these changes where made in separate writes, taking up all the time which could potentially be gained. This experiment was ditched. I also noticed that there was some issues with using the BREAK condition to reset my device. The manual says a BREAK condition should be able to reset the device. I'm communicating with iButtonLink regarding this, and they are looking in to it, believing I've found a bug. Today I actually noticed that sending a break DOES work, but only when inside b mode (sending bytes to the wire). To be strict, the manual actually only talks about break support in the sections regarding the different data modes.. So might actually be working as intended. Anyway, one brute force way of resetting would thus be to send b, then break, then re-probe at 9600bps.. But I'll wait for further response from their developers before doing anything with this. --- The changes adds the following: * A LIBFTDI configure option: if not auto-detected/forced-yes, all ftdi related code is dropped out using similar conditionals as for example the W1 code. * A new device arg: --linkusb=serial which tells owfs to use libftdi to find a specific USB device with that serial. * Improved performance, if using the new device arg. Some examples: Reading a DS18S20 temperature (12bit, after simultaneous conversion. 9 byte response): - Old LINK code: 123ms (- Old LINK code with FTDI latency timer externally set to 1ms: 75ms) - New LinkUSB FTDI code: 51ms For the DS18B20 the improvement is actually even better, a separate commit is already merged into master [2], and without that fix the DS18B20 took 250ms. Reading DS18*20 /power data (1 byte response): - Old LINK code: 100ms - New LinkUSB FTDI code: 43ms The code is available in a branch on my fork: https://sourceforge.net/u/stromnet/owfs/ci/ftdi-linkusb/. The changes can roughly be summarized: * A new file ow_ftdi.c has been added, implementing a new com_type ct_ftdi * ow_com* has been altered to support ct_ftdi in addition to ct_serial * ow_link.c is mostly untouched, with exception for the Link detection code which now tries to detect a link device using multiple baud rates. For old link mode, this should not introduce any changes at all, except that it now has a chance to find
Re: [Owfs-developers] Support for LinkUSB via libftdi
This is incredible work. Definitely will add to the master branch once the final touches and test are done. It's easy, using libusb, to read the vendor/product code. We do it for DS9490R adapters now. Beyond vendor/product codes, there are many other USB strings. One of them might be characteristic of all the relevant FTDI adapters, even custom runs. Paul On Sun, Jun 22, 2014 at 5:20 PM, Johan Ström jo...@stromnet.se wrote: Oops, git link fixes: https://sourceforge.net/u/stromnet/owfs/ci/ftdi-linkusb/tree/ (links to full tree, not only latest commit.. Click History to see all commits) And anonymous R/O clone command: git clone git://git.code.sf.net/u/stromnet/owfs owfs-stromnet On 6/22/14 23:09 , Johan Ström wrote: Hi, I've previously mentioned my work on LinkUSB performance improvements [1], and my goal to write a libftdi based implementation. The client-timings are generally cut about 2.5 times, depending on operation. A temp sensor is read in ~50ms instead of ~123ms. I now have some code which works fine, I'm running this with my LinkUSB 1.5 on FreeBSD 9.2, performing temperature readings of 24 mixed temperature sensors, and 4 DS2406's. The temperature is read every 30 seconds, and I (try to) scan for alarm ever 0.3 seconds. In other words, pretty heavy load. This has been running for a few days without any problems now. -(TL;DR below)- Some background (partly recap from earlier thread, but some new facts, and also repeating here to keep it gathered): This might be seen as micro-optimization, not really useful if you have a small net with few sensors. However, with a couple of DS2406's wired as inputs, I want as low reaction time as possible. This is quite a big step towards that goal. Other optimizations I'm doing is of course simultaneous conversions and using alarms etc, but that's another story. It all started with the random outages I wrote about in the other thread, in which I got some tips on the LinkUSB's different baudmodes. While looking into this, I also noticed that my DS2480B-based lab net performed much faster than the LinkUSB-based net. After some digging I found a few areas which could be improved. It boils down to mainly two things: * The FTDI FT232R (USB-RS232) chip which the LinkUSB utilizes, does not perform well with low amounts of data. The 64byte data buffer is by default flushed every 16ms, or when full. Most OWFS operations does not produce those amounts of data, so every transaction was delayed up to 16ms. This has been mitigated by changing the FTDi chip timer to 1ms, and this is also the main reason libftdi is used. (FTDI docs calls this the latency timer) * The LinkUSB operated at 9600bps by default. Every sent byte on the 1-wire bus is transmitted hex encoded, so 2 bytes is used for every single wire-byte. The DS2480B uses raw bytes, thus the LinkUSB yielded half the speed. This has been mitigated by using 19200bps instead of 9600bps. Higher speed (38400) is not usable, since it overruns the 1-Wire bus unless we take special care of rate-limiting. Could maybe be used to speed up the search functionality.. A third thing I made some experiments on was the fact that OFWS jumps in and out of byte mode. However, trying to setting this mode explicitly and going in/out from it only when it was actually required, yielded worse timings in the end (with the above fixes applied).. Most likely since these changes where made in separate writes, taking up all the time which could potentially be gained. This experiment was ditched. I also noticed that there was some issues with using the BREAK condition to reset my device. The manual says a BREAK condition should be able to reset the device. I'm communicating with iButtonLink regarding this, and they are looking in to it, believing I've found a bug. Today I actually noticed that sending a break DOES work, but only when inside b mode (sending bytes to the wire). To be strict, the manual actually only talks about break support in the sections regarding the different data modes.. So might actually be working as intended. Anyway, one brute force way of resetting would thus be to send b, then break, then re-probe at 9600bps.. But I'll wait for further response from their developers before doing anything with this. --- The changes adds the following: * A LIBFTDI configure option: if not auto-detected/forced-yes, all ftdi related code is dropped out using similar conditionals as for example the W1 code. * A new device arg: --linkusb=serial which tells owfs to use libftdi to find a specific USB device with that serial. * Improved performance, if using the new device arg. Some examples: Reading a DS18S20 temperature (12bit, after simultaneous conversion. 9 byte response): - Old LINK code: 123ms (- Old LINK code with FTDI latency timer externally set to 1ms:
Re: [Owfs-developers] Support for LinkUSB via libftdi
Thank you! Looking forward to feedback from more experienced owfs-eyes.. :) Scanning the USB bus for vid/pid should be no problem. However, the DS9490R seems to use a special vid/pid, where the LinkUSB uses a generic any-kind-of-ftdi-based-adapter-vid/pid. Unfortunately the dumped strings doesn't seem to help much either: My LinkUSB: ugen4.2: FT232R USB UART FTDI at usbus4, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (90mA) bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0200 bDeviceClass = 0x bDeviceSubClass = 0x bDeviceProtocol = 0x bMaxPacketSize0 = 0x0008 idVendor = 0x0403 idProduct = 0x6001 bcdDevice = 0x0600 iManufacturer = 0x0001 FTDI iProduct = 0x0002 FT232R USB UART iSerialNumber = 0x0003 A900fx3D bNumConfigurations = 0x0001 Compared to another RS232-dongle (identical fields omited): ugen3.3: USB FAST SERIAL ADAPTER FTDI at usbus3, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (44mA) bcdUSB = 0x0110 iProduct = 0x0002 USB FAST SERIAL ADAPTER iSerialNumber = 0x0003 FTCDDBSX Not so much to go on.. the iProduct string is different, but I bet the chip is not exactly the same, and that any FT232R based design identifies itself as FT232R USB UART.. Johan On 23/06/14 00:44, Paul Alfille wrote: This is incredible work. Definitely will add to the master branch once the final touches and test are done. It's easy, using libusb, to read the vendor/product code. We do it for DS9490R adapters now. Beyond vendor/product codes, there are many other USB strings. One of them might be characteristic of all the relevant FTDI adapters, even custom runs. Paul On Sun, Jun 22, 2014 at 5:20 PM, Johan Ström jo...@stromnet.se mailto:jo...@stromnet.se wrote: I do have one thing on the todo list, and that is auto-detection. Currently you have to explicitly specify a LinkUSB FTDI serial number (Linux: lsusb, FreeBSD: usbconfig). This is not very optimal. However, at least my device uses the standard FTDI Vendor/product ID. This means I cannot distinguish a random FTDI-based RS232-adapter and a LinkUSB, without actually talking to the device. This can of course be done, but I'm not sure it's acceptable to start writing to every FTDI adapter found.. How is this solved with other auto-detected devices? Looking forward to any and all feedback! :) Johan [1] https://sourceforge.net/p/owfs/mailman/owfs-developers/thread/53905A08.40906%40stromnet.se/#msg32422357 [2] https://sourceforge.net/p/owfs/code/merge-requests/1/ -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net mailto:Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
