Hi,since nobody have yet to create a FreeBSD ports package for owfs, I took some time do that, don't like to run stuff from my homedir.. ;)If anyone cares to take a look at it, I'd appreciate. I haven't submitted it to the FreeBSD team yet, it doesn't really feel that stable in regards to dependenc
Hi list!
I've been looking into building custom slaves (private use only) using Atmel's
AVR processor. As subscribers of this list is aware of this has been discussed
here before, but from what I gather from the archives, they never really
amounted to any real conclusion on what works or not, a
rystal tomorrow, but I'm not hoping too much.
Johan
On Apr 9, 2012, at 21:00 , Patryk wrote:
> Dnia 09.04.2012 o 20:26 Johan Ström Johan Ström
> napisał(a):
>
>> Hi list!
>>
>> I've been looking into building custom slaves (private use only) using
>&
Hi Nathan!
That sounds interesting! I'm not sure the code is the problem, the logic is
quite clear, it's probably more about getting the timings right. With 20MHz
timing would be much more accurate. But the more working examples the better,
if you have time, the community (at least me.. ;)) wou
Hi,a few years ago I wrote a basic FreeBSD port for owfs [1]. I have now updated it with the latest owfs release and also improved port with regard to config options etc.The patches have been submitted separately [2], but the attached shar file contains the same patches.Some features are known brok
Great, thanks! I'll look out for a release and update the port accordingly.
Regarding swig, I have never dealt with any swig stuff before, so it might just
be some lookup/path/config problem.. or something much more complex! I did not
really put that much time to it since I do not use it for the
Hi,
I'm testing the 2.9p3 release on FreeBSD 8.4. I'm currently running
2.9p1 without problems, but with p3 it seems the owserver want's to exit
as soon as it has served a single request?
Running my main owserver (2.9p1) on port 4304, starting the p3 server on
4305:
$ export LD_LIBRARY_PATH=/usr
c/include/ow_debug.h?r1=1.31&r2=1.32
If debug is on:
http://owfs.cvs.sourceforge.net/viewvc/owfs/owfs/module/owlib/src/c/error.c?r1=1.41&r2=1.42
if debug is on)
On 4/2/14 07:42 , Johan Ström wrote:
> Hi,
>
> I'm testing the 2.9p3 release on FreeBSD 8.4. I'm currentl
sh under linux.
>
> I'm tempted to leave the error handling alone, unless you wish otherwise.
>
> Paul Alfille
>
> The error is fixed in the CVS and will be fixed in the next release.
>
>
> On Wed, Apr 2, 2014 at 2:55 PM, Johan Ström <mailto:jo...@stromnet.se>
Hi,
I've posted about a FreeBSD port ("package") earlier, and I have now
updated it with 2.9p3.
This also enables python and perl support which was broken in my last
port. PHP is still wreaked though..
The patches submitted in https://sourceforge.net/p/owfs/patches/19/,
https://sourceforge.net
Hi!
I've been experimenting for a while to get good results with a DS2406
configured for input, utilizing the edge detector latch feature (this
would probably apply to DS2408 which also has this feature).
Since this haven't been as simple as "connect the switch between GND and
PIO", I'd thought I
On 4/28/14 15:29 , Jan Kandziora wrote:
> Am 28.04.2014 13:50, schrieb Johan Ström:
>> Mostly this has been working good, with reliable triggering of the
>> latch. However, one problem with pull-up based circuit is that I get
>> erroneous triggers if VCC disappears, for
On 4/28/14 15:45 , Johan Ström wrote:
> On 4/28/14 15:29 , Jan Kandziora wrote:
>> Am 28.04.2014 13:50, schrieb Johan Ström:
>>> Mostly this has been working good, with reliable triggering of the
>>> latch. However, one problem with pull-up based circuit is that I ge
Hi,
big up for git.. :)
Compiles fine on FreeBSD now, without any extra patches! Haven't tried
to use it yet though. If it works OK I will probably submit the owfs
port to the ports system.
/Johan
On 4/30/14 02:35 , Paul Alfille wrote:
> Release Notes owfs 2.9p4
> 4/30/2014
>
> New features
> 1
ret=-5
DEBUG: to_client.c:(76) payload=0 size=0, ret=-5, sg=0x10A offset=0
DEBUG: to_client.c:(85) No data
DEBUG: data.c:(227) Finished with client request
DEBUG: handler.c:(135) OWSERVER handler done
DEBUG: ow_net_server.c:(238) Normal exit.
On 4/30/14 11:15 , Johan Ström wrote:
Hi,
big
Great work! A quick test on my lab net indicates all fine!
/Johan
On 5/2/14 17:48 , Paul Alfille wrote:
> Thanks to quick testing by Stefano Miccoli and Johan Strom!
>
> Release Notes owfs 2.9p5
> 5/2/2014
>
> Fixes some show-stopper bugs in 2.9p4
> Fixes:
> 1. Token creation problem from Stefan
Hi,
I got a LinkUSB as a master for my 1-wire net, around 80m with 30 devices.
The bus is scanned every minute and temperature sensors polled (most of
the devices). Around 3 times a second I try to scan the alarm dir for
alarms (DS2406's), and possibly handle these.
Normally this works perfectly
current /dev/ttyUSBx device.
SUBSYSTEM=="tty", \
ATTRS{product}=="FT232R USB UART", ATTRS{serial}=="", \
SYMLINK+="linkUSB0", GROUP="owfs"
where of course you have to substitute with the actual serial
number. BTW I also set
On 6/6/14 16:23 , Johan Ström wrote:
...
I did some speed experiments, with interesting outcome...
This was done by manually telling the LINK to use a certain baudrate,
and then start owserver with that setting.
At 9600 bps, a full owdir (uncached) takes ~ 1700ms on my 30 devices.
A owread
was well worth the time :)
I'll keep on experimenting, and I'll work on a proper patch (libftdi
optional of course)!
/Johan
On 6/7/14 12:47 , Johan Ström wrote:
On 6/6/14 16:23 , Johan Ström wrote:
...
I did some speed experiments, with interesting outcome...
This was done by manu
l adapter
anither day with a very nice latency, i will check what chip
Em segunda-feira, 9 de junho de 2014, Johan Ström <mailto:jo...@stromnet.se>> escreveu:
A quick, positive (40% faster) update:
I've implemented mode-toggling as described below (keep mode
between LIN
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 f
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 , J
em 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 <mailto:jo...@stromnet.se>> wrote:
>
>
>
> > I do have one thing on the todo list, and that i
. But since this
> would only be an optional test it might be a good solution.
>
>
> On Mon, Jun 23, 2014 at 1:54 AM, Johan Ström <mailto:jo...@stromnet.se>> wrote:
>
> Thank you! Looking forward to feedback from more experienced
> owfs-eyes.. :)
>
> Scan
l serial
> ports. Now that most ports are USB emulations, perhaps we can move to
> an all-scanned solution (i2c, USB, USB/serial, some of the ethernet).
>
>
>
> On Mon, Jun 23, 2014 at 9:09 AM, Johan Ström <mailto:jo...@stromnet.se>> wrote:
>
> Afaik, the LinkUSB is
ng, I'm OK with leaving it as is (or
possibly just move to --usb with specific identification), I only have a
single LinkUSB anyway..
Johan
On 6/24/14 08:43 , Johan Ström wrote:
1A: Yes, this is what regular --link does now
1B: With --linkusb and a serial number. It does not use the se
Hi,
I'd like to announce that my efforts to get OWFS into the FreeBSD ports
tree has been successful!
With the help of commiter John Marino we now have
http://www.freshports.org/comms/owfs, FreeBSD users should thus be able
to install owfs using their package manager.
Regards
Johan
--
Hi,
I've noticed some problems using a FTDI based USB serial dongle together
with a DS2480B based adapter (also known as DS9097U).
On startup the device was not recognized at all, complaining about wrong
responses. Anyone else seen these issues?
I've debugged the problem and found the cause.
On s
just the slurp time-out, and
perhaps some of the FTDI timing parameters. Also there is a 0-baud
issue which we should look at fixing on our end as well. Is it the
serial "BREAK" or baud changed that does it?
Paul
On Fri, Sep 19, 2014 at 2:57 AM, Johan Ström <mailto:jo...@stromnet.se&
type of USB adapter and can send any tuning parameters at the start.
1-wire communication messages are pretty short, and often of variable
length. You test shows some nice speed increases with better timing
choices. I'd like to incorporate that eventually.
Paul
On Sun, Sep 21, 2014 a
On 22/09/14 00:21, Robin Gilks wrote:
>> 1. Trying to resolve a serial port TTY name (i.e. /dev/cuaU1 on FreeBSD)
>> to a potential USB device is probably doable, but not without a lot of
>> effort and OS specific code.
>> I don't think it's worth trying to go down that road.
>>
> How about using
Net
OWSERVER-ENET
w1
Hardware serial will always be a problem, but some USB-serial might be
possible.
Paul
On Mon, Sep 22, 2014 at 2:59 AM, Johan Ström <mailto:jo...@stromnet.se>> wrote:
On 22/09/14 00:21, Robin Gilks wrote:
>> 1. Trying to resolve a serial port TTY n
I have a v1.5).
So, how do we address the others?
Paul Alfille
On Tue, Sep 23, 2014 at 3:40 PM, Johan Ström <mailto:jo...@stromnet.se>> wrote:
I'm all for auto-detection, when it is possible to do so reliably.
As you mentioned in the other reply, randomly poking at stu
10c4:ea60 -- CP210x Unclear if it's generic or not
>>> USB9097 --1a86:7523 -- HL-340 Seems generic
>>> ECLO -- 0403:ea90 -- FTDI with UNIQUE product ID
>>> MasterHub -- 04d8:f897 -- MTI with UNIQUE product ID
>>> DS9490R -- 04fa:2490 --
I with UNIQUE product ID
>>> MasterHub -- 04d8:f897 -- MTI with UNIQUE product ID
>>> DS9490R -- 04fa:2490 -- Maxim with UNIQUE ID
>>>
>>> So it looks like only ECLO, the new Hobby Boards MasterHub,
>>> and the DS9490R can be
Hi, thanks for your feedback!
On 9/30/14 20:08 , Der Tiger wrote:
> ReHi Johan,
>
> On 30/09/14 08:32, Johan Ström wrote:
>> * auto-detection can only be relied on for certain pure USB devices
>> * auto-detection can not be relied on when "standard" serial bridge
On 9/30/14 15:50 , Stefano Miccoli wrote:
On 30 Sep 2014, at 08:32, Johan Ström <mailto:jo...@stromnet.se>> wrote:
Hi all,
picking this up again. Lets summarize the main points:
* auto-detection can only be relied on for certain pure USB devices
* auto-detection can not be relie
ter
> 3. Improved systemd support -- Tomasz Torcz
>
> Fixes
> 1. Mutex errors and checking, including read-write lock error --
> Christian Magnusson
> 2. Longer timeput needed for FTDI serial adapters -- Johan Ström
> 3. FreeBSD fixes -- Johan Ström
> 4. mucl C library sup
midity
> C. Barometer
> 3. Improved systemd support -- Tomasz Torcz
>
> Fixes
> 1. Mutex errors and checking, including read-write lock error --
> Christian Magnusson
> 2. Longer timeput needed for FTDI serial adapters -- Johan Ström
> 3. FreeBSD fixes -- Johan Ström
> 4.
file*
>Name of an *owfs* *(5)* configuration file with more
> command line parame-
>ters
>
> but cannot be processed alone, since most of the man pages
> machinery is loaded by the "master" man page.
>
> On 09 Oct 2014, at
Hi,
I noticed on my DS9097U adapter, hooked on via FTDI USB dongle, that it
would not come back up online after a owfs restart, if the latest
executed command was in DATA mode.
After lots of testing and debugging, I got a patch which solves the
problem. It introduces a 500ms delay before tcsend
Hi,
I was notified that owfs 2.9p8 fails to build on FreeBSD 8.4 and 9.1,
seemingly due to a portability issue in the new manpages Makefiles.
Not sure why it fails on these older FreeBSDs, when it works on 10.0..
But both 8.x and 9.x is on extended support so it would be nice if we
could build
u
> are using autoconf and all of its ancillary programs then you must
> have a fairly new and updated GNU-Make.
>
> Which version of GNU-Make (or which other breed of make) is packaged
> with FreeBSD 8.4 and 9.1?
>
> I will provide a patch soon for fixing this.
>
> S.
an3/DS28EA00.3.gz
man/man3/DS28EC20.3.gz
man/man3/EDS.3.gz
man/man3/EEEF.3.gz
man/man3/LCD.3.gz
man/man3/mAM001.3.gz
man/man3/mCM001.3.gz
man/man3/mDI001.3.gz
man/man3/mRS001.3.gz
man/man3/owperl.3.gz
man/man5/owfs.5.gz
man/mann/owtcl.n.gz
On 17/11/14 13:49, Johan Ström wrote:
> GNU make is not u
s disabled under BSD and OSX, so please check if in
previous versions the missing files were present.
On 05 Dec 2014, at 08:40, Johan Ström <mailto:jo...@stromnet.se>> wrote:
Hi,
while waiting for patches, I tried the alternative approach using GNU
make when building on < Fr
FYI: the FreeBSD port is now updated to use gmake.
Regarding causing problems, the man page installation was already
severely broken on FreeBSD (I think) so it was just as well, so we found
the issue. So, no worries!
Happy holidays!
Johan
On 12/22/14 12:37 , Stefano Miccoli wrote:
You are r
Hi Matthias!
Nice to see continued work on the original (smurfix/)owslave code. I've
got some similar code, forked from the taliesin fork originally form
your code (according to githubs network view). Your code (today) is
definitely smaller than what I've got now. I think I've tried yours way
Hi,
The LINK adapter has an extra AUX line which can be used as a general
I/O port (somewhat limited though).
I've added some code to control this line via owfs:
--
Dive into the World of Parallel Programming The Go Par
Oops, early send... Trying again, this time writing the full mail!
The LINK adapter has an extra AUX line which can be used as a general
I/O port (somewhat limited though).
Some background, from LinkUSB manual page:
---
The LinkUSBTM supports the standard RJ45 type 1-Wire bus connection
wher
write-only from the name.
How about auxpower and auxsense?
On Thu, Mar 12, 2015 at 12:37 PM, Johan Ström <mailto:jo...@stromnet.se>> wrote:
Oops, early send... Trying again, this time writing the full mail!
The LINK adapter has an extra AUX line which can be used as a
general I/O
n, or even better, solved, similar issues, ideas
are welcome!
On 3/14/15 02:06 , Paul Alfille wrote:
Great idea!
On Fri, Mar 13, 2015 at 1:48 PM, Johan Ström <mailto:jo...@stromnet.se>> wrote:
Indeed, one is read only and one is write only. The reasoning
behind two separate nod
Hi,
just want to give +1 for pyownet. I'm using it for my network and it
works 100% flawless, scanning the alarm dir ~10 times per second and the
full bus every 30 second, reading ~25 temperature sensors every 30 seconds.
This have been running for about a year now, using my own master
software w
Hi,
every now and then I've noticed how my DS2480B-based adapter on my lab
network seems to stop responding. Restarting OWFS has always solved the
issue for the moment.
TLDR: Shouldn't DS2480_big_configuration be called on comm failure?
Longer version:
---
The reset & Presence command works fin
VEL_DEBUG("Bad response error. Reconnection
%d/%d",pn->selected_connection->reconnect_state, reconnect_error);
return gbBAD ;
}
return gbGOOD;
}
Regards
Johan
On 03/07/15 18:40, Johan Ström wrote:
> Hi,
>
> every now and then I&#
Owslave has been superseeded by the M-O-A-T project:
https://github.com/M-o-a-T/moat, and from my brief use (a few months
back, testing only) it works really well, at least on a Mega 8. There
was an introductory post on this list a few months back.
You need to edit the .cfg file to build a con
What does debug logging reveal? Configure & build with "--enable-debug
--enable-owtraffic" and then running with "--foreground --debug" usually
gives a very verbose idea on what's going on.
Is the stacktrace always ending up in libusb? Could possibly indicate
duplicate libusb_close calls or some
On 05/09/15 09:21, Matthias Urlichs wrote:
> Johan Ström stromnet.se> writes:
>
>> What does debug logging reveal? Configure & build with "--enable-debug
>> --enable-owtraffic" and then running with "--foreground --debug" usually
>> gives a v
On 06/09/15 16:45, Matthias Urlichs wrote:
> Johan Ström stromnet.se> writes:
>> Ok, very early crash then. Does it help buidling with --disable-zero?
>>
> Will try.
>
>> Do you have the gdb output from this as well? The above looks more like
>> a syscall
On 05/10/15 15:54, Jan Kandziora wrote:
> Am 05.10.2015 um 14:23 schrieb Alex R. Gibbs:
>> However, other clients will have to wait if they happen
>> to query owserver during the conversion/read.
>>
> No. That can only happen if you use parasite powered sensors. Because
> parasite power occupies th
Run owserver (or whatever you use) with --traffic. Not sure if you need
to compile with debug, but I don't think so.
On 21/10/15 12:25, rot...@gmx.de wrote:
> Hi Alex,
>
> >I’ve never done a “full byte dump” before so if you can give me some
> sort of recipe to produce what you want, I should be
Oh, and --foreground is useful too.
On 21/10/15 13:18, Johan Ström wrote:
> Run owserver (or whatever you use) with --traffic. Not sure if you
> need to compile with debug, but I don't think so.
>
> On 21/10/15 12:25, rot...@gmx.de wrote:
>> Hi Alex,
>>
>>
Try --traffic (two dashes)
On 21/10/15 14:58, Alex Shepherd wrote:
>>
>> Oh, and --foreground is useful too.
>
> Hmmm…
>
> I tried to run it using:
>
> /usr/bin/owserver -c /etc/owfs.conf --foreground —traffic
>
> but got an error:
>
> /usr/bin/owserver: unrecognized option ‘—traffic
>
> Here is s
--000: E1 55 28 10 92 BF 03 00 00 9E
<.U(...>
DEBUG: ow_tcp_read.c:(63) attempt 9 bytes Time: 5.00 seconds
I have no clue about the state of rpi builds though, the list may help
further!
Regards
Johan
On 21/10/15 15:15, Alex Shepherd wrote:
>
> Hi Johan,
>
>> O
Hi,
a ticket was opened a few days ago regarding merging the "moat" device
specific owfs code into master:
http://sourceforge.net/p/owfs/feature-requests/9/
Does anyone object that I merge this? I've run this code myself for
months without any issues.
The only reason I can come to think of is
.
On 10/11/15 20:32, Colin Reese wrote:
> Is this still only for attiny? I've been limping along with code for
> atmega328 from elsewhere and would love if someone has time to help me port
> it. I love the idea.
>
>> On Nov 10, 2015, at 11:10 AM, Johan Ström wrote:
>>
local IO (and other arbitrary
> values like serial), my end goal, I'd much rather get moat working.
>
> C
>
>> On Nov 10, 2015, at 12:16 PM, Johan Ström wrote:
>>
>> While I haven't tested it myself, there are specific code for mega328
>> (and 168,
headers?
Johan
On 11/11/15 09:09, Colin Reese wrote:
> I get a number of errors on compile similar to:
>
> /moat.c:182: undefined reference to `pgm_read_ptr_near'
>
> C
>
> On 11/10/2015 1:07 PM, Johan Ström wrote:
>> _include: world.cfg
>> d
11/11/15 11:04, Colin Reese wrote:
> I have tried on deb Linux (Ubuntu 14.04) with apt distros, also winavr. Just
> downloaded owslave and tried fresh with the exact cfg you listed.
>
> C
>
>> On Nov 11, 2015, at 1:57 AM, Johan Ström wrote:
>>
>> Hm,
As long as your built it for 16MHz it should probably be compatible (I'm
not familiar with any specific fuses the m328 might have).
Thus, f_cpu: 1600
On 12/11/15 03:39, Colin Reese wrote:
> So to avoid trying to get WinAVR to behave, on a windows machine with
> avrdude I would do something l
a88__) ||
defined(__AVR_ATmega328__)
// Clock is set via fuse
is the f_cpu definition necessary here?
C
On Thu, Nov 12, 2015 at 8:44 AM, Johan Ström <mailto:jo...@stromnet.se>> wrote:
As long as your built it for 16MHz it should probably be
compatible (I'm
no
nd, but if not already defined, what is the default value?
Or, why is this not defined in the code already?
On Thu, Nov 12, 2015 at 9:13 AM, Johan Ström <mailto:jo...@stromnet.se>> wrote:
Yes, the f_cpu define only controls timing calculations, which
must match the clock speed. I
lts.types
>> code: []
>> m328test:
>> _ref: mcu.mega328
>> defs:
>> f_cpu: 1600
>> port:
>> 1: B0~
>> 2: B1~
>> onewire_id: x0f361b8bff8a
>>
>>
>> On 11/12/2015 12:28 PM, Johan St
with my LV library and do not receive a response.
Is uart debug as simple as enabling it and then inserting uart_putc()
and uart_puts() statements where I see fit?
C
On 11/13/2015 12:05 AM, Johan Ström wrote:
Ah, using the latest code is always a good start.. :)
Yes, the 'moat' devi
be uphill.
C
On 11/13/2015 11:05 AM, Johan Ström wrote:
Not sure if there is any good docs on this yet, don't think so, and
the code has a quite a few "clever tricks" which minimizes size &
enhances customability but makes it a bit tricky to follow for the
uninitiated.
Basic
part!
I am good to go with git (https://github.com/iinnovations)
I'll give the owfs a build and throw it on a machine and see what I see.
Thanks for the help!
C
On 11/13/2015 11:50 AM, Johan Ström wrote:
Just sending F2 does not work, no. You need to send F2, then two more
bytes ide
That's not moat-related, nor owfs-related: "Internal compiler error".
I'd check for updates on your env, or change Linux dist or something.
For the record, line 476 of ow_moat.c is
static ZERO_OR_ERROR FS_r_alarm_status(struct one_wire_query *owq)
i.e nothing fancy at all.
On 16/11/15 01:10, C
Actually, it seems the master branch of https://github.com/M-o-a-T/owfs
is broken.. In July, a similar bug was fixed (segfault on owdir), which
was fixed with https://github.com/M-o-a-T/owfs/pull/2.
This has been working fine since then, but after the latest merges into
master (bb9d4027713644d7a
On 23/11/15 20:20, Jan Kandziora wrote:
> Am 23.11.2015 um 19:15 schrieb Colin Reese:
>> No, I am indeed using:
>>
>> https://github.com/M-o-a-T/owfs.git
>>
>> Where is the main archive?
>>
> $ git clone git://git.code.sf.net/p/owfs/code owfs-code
>
>
Note that it is the main *owfs* repo. There is
On 24/11/15 17:56, Matthias Urlichs wrote:
> On 24.11.2015 17:10, Matthias Urlichs wrote:
>> I'll take a look ASAP.
> I have rebased my "master" branch. Seems I mistyped a branch name
> yesterday. Sorry about that.
Great! For you git new-comers, 'git pull' will most likely not work
properly here
On 25/11/15 14:56, Jan Kandziora wrote:
> Am 25.11.2015 um 10:03 schrieb Stefano Miccoli:
>> Cannot check right now, but if I didn’t do something terribly wrong I
>> should be at the latest commit on master, so below e85572.
>>
>> It seems to me that actually e85572 introduced the bug:
>>
>> http
On 26/11/15 23:06, Jan Kandziora wrote:
> Am 26.11.2015 um 22:55 schrieb Johan Ström:
>> Re-adding the -EISDIR check fixes the issue (but, I assume, restore the
>> original external issue).
>> If we have no proper fix for the original external issue right now, I
>> s
Great!
On 14/01/16 16:28, Jan Kandziora wrote:
> Hi,
>
> as Paul seems to be unavailable and noone else dashes to the front, I
> claim benevolent dictatorship to decide we should have a 3.1p1 release
> including all the remaining patches from Paul and the recent fixes from
> Johan, Tomasz and myse
Hi,
some of you may remember my earlier attempts to add a libftdi based
LinkUSB interface into master. For reference:
http://sourceforge.net/p/owfs/mailman/message/32492037/
In short, the client-timings are generally cut about 2.5 times,
depending on operation. A temp sensor is read in ~50ms i
Hi, thanks for your input!
On 27/01/16 18:40, Stefano Miccoli wrote:
Good news.
In a few days I will have an old LinkUSB available for testing,
although with a limited number of sensors only: I will try-out your
implementation.
Great! I've been running one LinkUSB and one DS2480B, FTDI-dong
On 27/01/16 23:09, Johan Ström wrote:
Hi, thanks for your input!
On 27/01/16 18:40, Stefano Miccoli wrote:
Good news.
In a few days I will have an old LinkUSB available for testing,
although with a limited number of sensors only: I will try-out your
implementation.
Great! I've
On 27/01/16 23:42, Jan Kandziora wrote:
> Am 27.01.2016 um 23:09 schrieb Johan Ström:
>> (libftdi *does* have a ftdi_usb_find_all but "list all" only works on
>> libftdi >= 1.x. And it only lists devices with *known* FTDI vid/pid's.
>> Let's say a
On 27/01/16 23:45, Stefano Miccoli wrote:
> Minor glitch on module/owlib/src/c/ow_ftdi.c:
>
> here you use MIN and MAX macros, which are defined in .
> Don’t ask me why, but this file is not included in linux:
>
> — form ow.h:
>
> #ifdef HAVE_SYS_TYPES_H
> #ifdef __FreeBSD__
> #include
> #endif
On 28/01/16 08:16, Johan Ström wrote:
> On 27/01/16 23:42, Jan Kandziora wrote:
>> Am 27.01.2016 um 23:09 schrieb Johan Ström:
>>
>>
>> I'm against putting the listing/probing code into owserver. We have
>> small tools for everything and shouldn't st
On 28/01/16 23:58, Jan Kandziora wrote:
> Am 28.01.2016 um 23:38 schrieb Johan Ström:
>> What do you think?
>>
> Sounds reasonable. But if you name it owusbprobe, it should be able to
> detect DS9490 and DS9481, too.
>
Actually, I think DS9490 is based on the DS2490 chi
On 29/01/16 08:28, Johan Ström wrote:
>
> Also, since we don't have any Prolific layer (yet), we must use the
> systems regular COM port emulation. This presents a new issue: doing so
> cross-platform.
>
Ehr, the issue is mapping the USB device to the correct /dev/ttyXX nam
On 29/01/16 15:02, Jan Kandziora wrote:
> Am 29.01.2016 um 08:28 schrieb Johan Ström:
>> On 28/01/16 23:58, Jan Kandziora wrote:
>>> Am 28.01.2016 um 23:38 schrieb Johan Ström:
>>>> What do you think?
>>>>
>>> Sounds reasonable. But if you
+1, I'm using my 1wire bus for more than temperature sensors, blocking
on something that does not need to block would ruin my setup (polling
alarms every 0.2s)
On 03/02/16 01:43, Jerry Scharf wrote:
> Hi,
>
> This would break my code. I send out simultaneous on each bus I have
> then come back aro
On 27/01/16 18:40, Stefano Miccoli wrote:
Good news.
In a few days I will have an old LinkUSB available for testing,
although with a limited number of sensors only: I will try-out your
implementation.
Stefano,
did you get any chance to give my ftdi code a spin?
Regards
Johan
---
On 29/01/16 16:54, Matthias Urlichs wrote:
> Hi,
>
> On 27.01.2016 23:45, Stefano Miccoli wrote:
>> #ifdef HAVE_SYS_TYPES_H
>> #ifdef __FreeBSD__
>> #include
> Umm, why doesn't this code use HAVE_SYS_PARAM_H ??
>
No idea, was not introduced in the ftdi branch. I've commited a fix
there now thoug
Hi,
at least the current master (or well, ftdi branch but nothing touched
there since 9a8aa0 == 3.1p1) detects libusb properly on my OS X (10.10.5):
checking for LIBUSB... yes
...
Compile-time options:
USB is enabled
I have no custom configure flags, and libusb from brew
On 29/01/16 15:02, Jan Kandziora wrote:
> Am 29.01.2016 um 08:28 schrieb Johan Ström:
>
>
>> As for the DS9481, it seems to be based on the Prolific PL-2303HXD chip,
>> a generic adapter chip similar to the FTDI. Behind that, it emulates a
>> DS2480B (owfs source cod
5446176
> DEBUG: ow_ftdi.c:(397) attempt 21474836481 bytes Time: 0.1995157928
> seconds
> DEBUG: ow_ftdi.c:(458) ftdi_read: 1 - 0 = 1 (3 retries)
> DEBUG: ow_ds9097U.c:(643) wrong response (E7 not 00)
> DEBUG: ow_ds9097U.c:(665) Failed second attempt at resetting baud
>
On 04/02/16 23:26, Jan Kandziora wrote:
> Am 04.02.2016 um 23:11 schrieb Johan Ström:
>> vid =0x0B6A, pid = 0x5A03
>> "This device is identified as a DS18E17 / DS9481P-300 USB adapter.
>> To use this, you need to use the DS2480B device, and point it to
>> the
On 10/02/16 08:25, Stefano Miccoli wrote:
On 10 Feb 2016, at 07:55, Johan Ström <mailto:jo...@stromnet.se>> wrote:
Basic functionality seems OK, but there is a sequence that breaks
the server.
$ owserver --link ftdi:i:0x0403:0x6001 --foreground
^C
$ owserver -d ftdi:i:0x04
1 - 100 of 213 matches
Mail list logo
