Back
[03:12:32] <cradek> jmkasunich: is your last fix right? it seems backward or something
[03:13:03] <jmkasunich> the one to the config loader?
[03:13:33] <cradek> changing "cardnum" to "0"
[03:13:38] <jmkasunich> its right
[03:13:46] <cradek> ok :-)
[03:13:55] <SWPadnos> that looks like an iterator variable, not a "target"
[03:14:00] <SWPadnos> from the diff
[03:14:11] <jmkasunich> later in the code, he does if (i++ == cardnum) { found the card we want }
[03:14:40] <jmkasunich> since he inited it to cardnum, it would always be satisfied by the first card it finds
[03:15:08] <jmkasunich> if you init i to zero, then the if is satisfied by the cardnum'th card you find
[03:15:27] <jmkasunich> the if (i++....) happens only when you find a 5i20 card
[03:15:28] <cradek> ok I see it now
[03:16:50] <cradek> that flow control is a little peculiar around there
[03:16:57] <jmkasunich> I think in my version, I inited it to -1, and did while ( i != cardnum ) { check for card }, so i is the number of the most recently discovered card
[03:17:07] <jmkasunich> that code is a little peculiar in general
[03:17:29] <jmkasunich> thats why I'm working on my own version, since I have to add stuff anyway to handle the config info
[03:17:42] <jmkasunich> I started with his, and filtered out a lot of the pecularities
[03:18:18] <jmkasunich> still a lot in there too, but that will slowly change. in fact, right now I researching the PCI stuff
[03:19:12] <jmkasunich> I think that code should be checking SUBSYSTEM_ID... as written, it would detect anything that uses a PLX9030 bridge chip, even if its not a 5i20
[03:22:11] <jmkasunich> its so tempting to use lspci to get that info
[03:22:53] <SWPadnos> there should be a PCI API for getting that, which is probably preferable
[03:23:17] <SWPadnos> in /proc or somewhere, if nothing else
[03:23:28] <jmkasunich> lspci reads /proc
[03:23:40] <jmkasunich> the existing code also reads proc
[03:23:51] <jmkasunich> /proc/bus/pci/devices to be precise
[03:24:40] <jmkasunich> usr/include/linux/pci.h has a lot of defines that can be used to help parse the data
[03:29:06] <jmkasunich> seems like the proper approach is to read /proc/bus/pci/devices looking for a device/vendor pair that seems right, then use the bus/slot/funct info from there to find a specific file like /proc/bus/pci/00/09.0
[03:29:27] <jmkasunich> which contains a minimum of 64 bytes of config info, in a format defined by pci.h
[03:29:54] <jmkasunich> if there is an api (other than open/read) I haven't found it yet
[03:30:03] <SWPadnos> hmmm
[03:30:50] <jmkasunich> how would one go about finding the source code for lspci or setpci?
[03:31:00] <cradek> lspci doesn't read /proc, it reads /sys/bus/pci/devices/*
[03:31:11] <SWPadnos> http://old.kernelnewbies.org/documents/kdoc/kernel-api/linuxkernelapi.html
[03:31:30] <SWPadnos> I'm not sure what kernel version that's for - haven't looked at it too closely
[03:31:42] <cradek> first figure out what package has lspci: dpkg -S lspci
[03:31:42] <SWPadnos> section 10 has the PCI support library functions
[03:31:45] <cradek> then apt-get source [that package]
[03:31:56] <jmkasunich> cradek: how did you determine what lspci reads?
[03:32:04] <cradek> strace -eopen lspci
[03:32:09] <SWPadnos> man lspci? ;)
[03:32:18] <jmkasunich> not man, I've already looked there
[03:32:25] <SWPadnos> heh - damn
[03:32:56] <jmkasunich> SWPadnos: I'm not looking for a kernel space api - this is user space
[03:33:07] <SWPadnos> hmm. indeed
[03:33:34] <cradek> pci_fill_info(p, PCI_FILL_IDENT | PCI_FILL_IRQ | PCI_FILL_BASES | PCI_FILL_ROM_BASE | PCI_FILL_SIZES);
[03:33:46] <jmkasunich> I think the actual driver does use the pci support library mentioned on that page
[03:34:22] <cradek> package is pciutils btw
[03:34:28] <cradek> (apt-get source pciutils)
[03:34:50] <jmkasunich> cradek: duh.... I was trying to find it on the web, forgot about apt-get source
[03:36:29] <jmkasunich> hmm... E: Unable to find a source package for pciutils
[03:37:01] <cradek> Directory: pool/main/p/pciutils
[03:37:22] <cradek> are you missing a deb-src line? just works for me
[03:37:28] <jmkasunich> checking that now
[03:39:21] <jmkasunich> thats better...
[03:39:35] <jmkasunich> (I had the source repos commented out...)
[03:41:46] <cradek> that's my favorite thing about debian: I [a regular old user] want to glance at the source for this thing I'm running
[03:44:36] <jmkasunich> pardon my stupidity, but now that I have the source package, where is it?
[03:46:44] <cradek> your current directory
[03:46:49] <cradek> all patched up and ready to compile
[03:47:05] <jmkasunich> oh....
[03:47:15] <jmkasunich> I was looking all over the /usr tree
[03:47:40] <jmkasunich> damn, I don't even remember what dir I was in when I gave that command
[03:47:49] <cradek> a user can't write there
[03:47:57] <jmkasunich> I'm used to apt-get putting stuff in the system, not my tree
[03:48:03] <cradek> in debian you don't have to be root to see the source to what you're running
[03:48:16] <jmkasunich> it makes sense when you explain it
[03:48:31] <jmkasunich> but I'm so used to "sudo apt-get foo" that I just did "sudo apt-get source foo"
[03:48:38] <SWPadnos> probably src/hal/drivers/mesa_5i20/firmware ;)
[03:49:08] <jmkasunich> ~/emcdev/emc2head ;-)
[03:49:46] <SWPadnos> heh - only a few levels off
[03:53:48] <jmkasunich> it looks like /proc/bus/pci/devices contains a subset of the data that you get from lspci -x, arranged in a somewhat different order
[03:55:22] <cradek> lspci.c: 'Can be freely distributed and used under the terms of the GNU GPL.'
[03:55:40] <cradek> why rewrite any of this?
[03:55:49] <jmkasunich> yeah, but I don't want to copy it... I'm tempted to invoke it
[03:56:41] <jmkasunich> the existing loader reads /proc/bus/pci/devices, and parses that output, which doesn't include the sybsystem info (a bug waiting to happen IMO)
[03:57:25] <jmkasunich> lspci gets all the data, and even filters it (I can invoke it with the desired vendor/device code, and it will only return data for cards that match
[03:58:09] <cradek> pciutils is not currently required
[03:58:19] <jmkasunich> true
[03:58:32] <jmkasunich> but isn't it part of the "base system" for most distros?
[03:58:33] <SWPadnos> 6 of one, half dozen of the other
[03:58:47] <cradek> jmkasunich: actually no - I think we've all installed it
[03:58:51] <jmkasunich> oh
[03:58:54] <SWPadnos> if you integrate the source, you're screwed if the kernel interface changes
[03:59:08] <SWPadnos> if you use lspci, you're screwed if the output format changes
[03:59:18] <cradek> SWPadnos: surely libpci.so will change with the kernel
[03:59:32] <cradek> I think compiling it is the better answer
[03:59:41] <SWPadnos> in the interest of reducing dependencies, I'd go for integration, personally
[03:59:43] <jmkasunich> yeah, lspci doesn't seem like the right answer either
[03:59:49] <cradek> parsing stdout of programs you don't control always sucks
[03:59:55] <cradek> parsing stdout of programs always sucks
[04:00:00] <SWPadnos> heh
[04:01:35] <jmkasunich> is /usr/include/pci/pci.h something that would be on most systems?
[04:01:52] <jmkasunich> * jmkasunich answers his own question: no
[04:02:03] <jmkasunich> I think thats part of pcituils-dev
[04:02:18] <jmkasunich> although I could copy the relevant parts of it
[04:02:23] <SWPadnos> that's probably OK for a development dependency
[04:02:23] <cradek> yes but with that scheme, it's a compile dependency instead of a runtime dependency
[04:02:37] <jmkasunich> ok
[04:02:56] <cradek> much better to add a compile dep than a runtime dep
[04:03:21] <jmkasunich> I figured out that /proc/bus/pci/00/09.0 (in my case) is the same as the output of lspci -s 00:09.0 -x, but in binary
[04:03:33] <jmkasunich> binary is better - because pci.h has the offsets to all the interesting stuff defined in it
[04:05:00] <jmkasunich> each line of /proc/bus/pci/devices starts with (in hex) a bus/slot/funct code, then a vendor/device code, so I can read that line-by-line to find candidates, then read the specific binary files to check the subsystem codes and get everything else I need
[04:06:41] <SWPadnos> is /proc expected to stick around for the next few years, or is it deprecated in favor of some /sys thing?
[04:07:24] <cradek> no idea...
[04:08:14] <SWPadnos> I think it's slated for removal "someday" - I just don't know when that day is supposed to be
[04:10:02] <jmkasunich> gawd, /sys is a maze of twisty little passages
[04:10:36] <jmkasunich> the same info is in there though
[04:10:43] <jmkasunich> in a differnt format of course :-(
[04:12:03] <jmkasunich> jmkasunich@ke-main-1006:~/emcdev/emc2head/pciutils-2.1.11$ cat /sys/bus/pci/devices/0000:00:09.0/subsystem_device
[04:12:04] <jmkasunich> 0x3131
[04:13:10] <jmkasunich> linux must be very efficient at opening and closing files, if it can use files to store one number
[04:13:36] <SWPadnos> those are phantom filesystems, so they should be very fast
[04:13:43] <SWPadnos> no storage used
[04:13:54] <jmkasunich> I know there not on disk, but still, gotta run the open system calls
[04:14:03] <jmkasunich> and traverse directory trees, and all that fun
[04:14:09] <jmkasunich> they're
[04:14:20] <SWPadnos> true
[04:14:51] <SWPadnos> ok. I'm not finding any info on deprecation of /proc, so I may be full of shit
[04:15:43] <a-l-p-h-a> was I kicked from #emc?
[04:15:50] <jmkasunich> I recall paul talking about /proc going away, but he never mentioned a timeframe
[04:17:00] <jmkasunich> a-l-p-h-a: it just says you left
[04:17:55] <a-l-p-h-a> jmkasunich, yeah... thanks
[04:21:16] <jmkasunich> SWPadnos: cradek: having installed the pciutils source package in a place where I didn't really want it...
[04:21:32] <SWPadnos> mv is your friend ...
[04:21:34] <jmkasunich> can I just delete the tree, or do I need to do some sort of apt-get remove?
[04:21:41] <SWPadnos> just remove it
[04:21:50] <jmkasunich> good
[04:22:05] <SWPadnos> as far as I know, it's not a package, and won't be updated
[04:24:33] <jmkasunich> damn, I'm the master of digression
[04:24:47] <SWPadnos> all hail the master
[04:25:05] <jmkasunich> this whole chase started because the code wasn't getting the right address for accessing the FPGA's memory block
[04:25:18] <jmkasunich> only then did I realize the subsystem codes should be dealt with
[04:25:53] <jmkasunich> turns out the problem with the memory block was just a bug in the original implementation, that data is available in /proc/bus/pci/devices, without going to the device specifci files
[04:25:58] <SWPadnos> don't call it a digression, call it "on-the-fly maintenance"
[04:26:27] <jmkasunich> well, I'm gonna let the subsystem thing go for now, and focus on the original task
[04:26:35] <jmkasunich> (which is user space access to the FPGA's config ram)
[04:26:44] <SWPadnos> maybe stick a note in the source
[04:26:48] <jmkasunich> good idea
[16:44:42] <SWPadnos> hmmm. so I'm looking through the "net" command, related to rugludallur's bug report
[16:44:57] <SWPadnos> I'm not sure how the problem should be fixed
[16:45:11] <SWPadnos> or if it needs to be fixed
[16:45:52] <jmkasunich> the first arg is always the name of the desired signal
[16:46:10] <jmkasunich> if it exists, add the following names (assumed to be pins) to it
[16:46:26] <SWPadnos> right. if that happens to be a pin name, then apparently nothing happens, but no error is given
[16:46:42] <SWPadnos> I need to check to see if a signal with the first pin name is created though
[16:46:49] <jmkasunich> the pin namespace and the signal namespace are separate
[16:46:51] <SWPadnos> but it wouldn't connect that pin
[16:46:55] <SWPadnos> yep
[16:47:13] <jmkasunich> so net foo bar should create signal foo and hook pin bar to it, even if there already is a pin called foo
[16:47:23] <jmkasunich> right, pin foo would not be connected to the signal
[16:48:07] <SWPadnos> right - that's why I'm not sure what the correct fix is, or if there is one :)
[16:48:22] <SWPadnos> should it be a warning if you create a net with only one pin?
[16:48:32] <SWPadnos> or if the net name matches a pin name?
[16:48:51] <SWPadnos> should it connect the pin of the same name (so it can be a direct replacement for linkpp)?
[16:50:51] <SWPadnos> it does act as we expect right now. a net with the first pin name is created, and the second pin is attached to it
[16:54:45] <jmkasunich> I want to strongly discourage linkpp style "net name same as pin name" stuff - its confusing
[16:54:57] <SWPadnos> yep
[16:55:09] <SWPadnos> does it make sense to refuse to make a net with only one pin connected?
[16:55:31] <SWPadnos> or make it an error if you use a net name that's also a pin name?
[16:58:31] <jmkasunich> net foo bar should be legal when foo already exists as a signal
[16:59:15] <SWPadnos> hmm. so if the preflight finds that the resulting net will have only one pin attached, then that could be flagged as an error
[16:59:27] <jmkasunich> and I don't see why net foo bar isn't legal to create a new signal foo and hook one pin to it
[16:59:34] <jmkasunich> (for example, if you want to use sets to test something)
[16:59:47] <SWPadnos> ok. it could be resolved as "works as designed, don't do that"
[16:59:54] <SWPadnos> sure
[17:00:09] <jmkasunich> maybe "if net name = pin name, gripe"
[17:00:33] <jmkasunich> that prohibits the linkpp style, and triggers on the "forgot the net name" user error
[17:00:38] <SWPadnos> yeah - that should catch any "sed s/linkpp/net/g" kind of problem
[17:00:41] <SWPadnos> yep
[17:01:19] <SWPadnos> ok. I may make that change later. gotta run for now (it's not snowing, so it's "play time" :) )
[17:01:30] <jmkasunich> heh
[17:10:38] <cradek> has anyone looked at holecircle?
[17:10:54] <jmkasunich> not me
[17:16:57] <jmkasunich> cradek: did you test my change to homing (error message if you try to home in teleop mode)?
[17:19:55] <cradek> yes
[17:21:22] <jmkasunich> it prints a message when you try to home in world mode?
[17:21:30] <cradek> yes
[17:21:32] <jmkasunich> so then I can close that bugreport.....
[17:21:37] <cradek> yay
[17:49:54] <jmkasunich> SWPadnos: you were a little faster...
[18:28:50] <alex_joni> hi
[18:31:50] <jmkasunich> hi
[18:32:06] <alex_joni> what's up?
[18:33:01] <jmkasunich> not much
[18:33:30] <cradek> jmkasunich: because you were connected to the cvs server about 6 times simultaneously and it doesn't like that
[18:33:41] <cradek> (I didn't know it was you at the time)
[18:33:41] <jmkasunich> strange
[18:33:43] <jmkasunich> when?
[18:33:50] <cradek> while I said that
[18:34:05] <jmkasunich> must have been the farm
[18:34:14] <jmkasunich> although that should be limited to 4 at once
[18:34:31] <cradek> there were at least 12 or so
[18:34:35] <cradek> maybe they each did it after every checkin
[18:34:39] <jmkasunich> I was afk, wasn't doing any updates
[18:34:53] <cradek> there were about 3 a minute for 5? minutes
[18:35:09] <cradek> no big deal
[18:35:10] <jmkasunich> you said "simultaneously"
[18:35:36] <cradek> yes
[18:35:36] <jmkasunich> there are 4 slots, each one does a cvs up on all three trees, but in sequence, not at the same time
[18:35:54] <jmkasunich> so you should see a max of 4 at one time, but 12 hits over some minutes
[18:35:56] <cradek> so there could have been 4 at a time, three times
[18:36:01] <cradek> ok
[18:36:19] <cradek> I need more computer for that.
[18:36:29] <jmkasunich> at the server you mean?
[18:36:55] <cradek> yeah
[18:37:13] <jmkasunich> ah, what made it worse - because the server got busy, the updates timed out, and then it retried
[18:37:19] <jmkasunich> so it just kept pounding
[18:37:29] <cradek> aha
[18:37:31] <jmkasunich> maybe I should do a sleep 60 or something after a failure?
[18:37:40] <cradek> nah I should get more machine
[18:37:45] <cradek> don't worry about it
[18:38:08] <jmkasunich> well, its kind of like the farm at this end - it bogs down when all are running at once, so I want more machine too
[18:38:23] <jmkasunich> but the other 99% of the time, its a non-issue
[18:38:37] <jmkasunich> I don't see any reason not to put the sleep in after a failed update
[18:38:45] <jmkasunich> under most conditions they don't fail
[18:39:19] <cradek> ok
[18:40:02] <jmkasunich> http://pastebin.ca/440021
[18:40:38] <jmkasunich> this is the log from the native slot (I was too lazy to fire up the VM console and look at those logs
[18:40:56] <jmkasunich> line 50 shows when it got busy
[18:41:19] <alex_joni> jmkasunich: I recently reinstalled vmware on my box
[18:41:34] <jmkasunich> and because all 4 tries timed out, it didn't even do the 2.1 build until the next commit
[18:41:41] <alex_joni> and I noticed the GUI version has a menu entry: resume target and run script
[18:41:58] <alex_joni> wonder if that wouldn't be a "smarter" thing to do..
[18:42:15] <jmkasunich> suspending and resuming has issues - the clocks get messed up, etc
[18:42:14] <alex_joni> manage the scheduling on your host (only let one run at once..)
[18:42:28] <jmkasunich> I'm too lazy to rewrite things
[18:42:34] <alex_joni> you can have ntpdate in the script..
[18:42:48] <alex_joni> but I agree it's probably a pita to get it right..
[18:42:52] <jmkasunich> yep
[18:43:34] <cradek> http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=120107786022
[18:43:45] <cradek> timeguy.com is one of these - it would be perfect for cvs
[18:43:55] <cradek> they have a real hard drive, not a slow laptop drive
[18:43:58] <jmkasunich> little
[18:44:12] <cradek> yeah, and usually no fan runs
[18:44:30] <jmkasunich> have you tried a RT latency test on one?
[18:44:56] <cradek> yes, it was fine, and had accelerated opengl (intel i810 video)
[18:45:10] <jmkasunich> oh, no PCI slots, never mind
[18:45:18] <cradek> the only minor problem is they have only 1 ram socket, and seem to only accekt 256MB
[18:45:20] <jmkasunich> * jmkasunich was thinking of a machine control
[18:45:36] <cradek> yeah for parport it would be fine, but not pci
[18:46:40] <jmkasunich> does it have ethernet? I don't see that mentioned on the auction
[18:46:46] <cradek> yes
[18:48:06] <jmkasunich> I think I've decided to start building myself a new computer....
[18:48:15] <jmkasunich> (only been talking about it for the last several months)
[18:50:08] <jmkasunich> right now the cvs server is a laptop, right?
[18:50:13] <cradek> yes
[18:50:26] <jmkasunich> are you sure the slowdown when I was hitting it was PC and not network?
[18:50:29] <cradek> it's in living area, so it should be small and quiet
[18:50:40] <cradek> jmkasunich: disk I'm pretty sure
[18:51:22] <jmkasunich> well, if you want to snatch that HP, I won't interfere ;-)
[18:51:33] <jmkasunich> but I'm gonna add that delay to the farm scripts
[18:51:48] <jmkasunich> having one give up for a while after a timeout should allow the other(s) to complete
[18:52:28] <jmkasunich> I suppose I could also lengthen the timeout itself - 2 mins might be too short
[18:52:50] <jmkasunich> for all I know, I aborted an update only a few seconds from completion, then immediately started another one
[18:53:43] <cradek> I'm allergic to buying hardware at a premium price because it comes with an illegit copy of windows
[18:53:59] <jmkasunich> when writing scripts, I tend to use short timeouts because it speeds testing - but in service, nobody cares about a few minutes
[18:54:17] <jmkasunich> that box? I'd hardly call $69 a premium price
[18:55:12] <jmkasunich> and you, unlike others, will NOT be contributing to piracy, because you'll wipe the illegal doze as soon as you get the box
[18:55:23] <cradek> $90 shipped
[18:55:39] <jmkasunich> its your DUTY to buy that machine, to prevent piracy! ;-)
[18:55:54] <cradek> :-P
[18:56:57] <jmkasunich> I didn't realize how much shipping was.... its funny, $69 is "cheap", but $90 isn't, even tho they really are not that far apart
[18:58:35] <cradek> the price is probably fair, but I don't want to pay it
[18:58:58] <cradek> oh comes with the keyboard and mouse - no wonder the shipping is high
[19:04:44] <jmkasunich> there, 3 min timeout, and 2 min wait before retry
[19:10:48] <cradek> thqnkw
[19:10:52] <cradek> thanks
[19:11:57] <jmkasunich> all VMs updated.... thanks for letting me know about it
[19:13:20] <jmkasunich> heh, you and I each spent almost as much on keyboards as that whole computer costs...
[19:14:53] <cradek> hmm
[19:14:56] <cradek> strange isn't it
[19:15:04] <jmkasunich> yeah
[19:15:28] <alex_joni> my keyb was about 150$
[19:15:54] <alex_joni> keyboard & mouse (wireless combo) actually
[19:18:03] <jmkasunich> wow:
http://dallur.com/typo3temp/pics/742be91049.jpg
[19:18:58] <alex_joni> yeah, that's a killer mobo
[19:19:43] <cradek> I'm anxious for 5-6 years from now when those kinds of machines are free...
[19:20:04] <jmkasunich> heh
[19:20:22] <jmkasunich> the problem with free is that you are _always_ several years behind
[19:21:25] <jmkasunich> I used surplus for a while, and still do for odd things, but my current main box was built from new parts (mobo, cpu, disk, pase, and ps, I reused some other stuff)
[19:21:31] <jmkasunich> it cost me about $300 2 years ago
[19:21:54] <jmkasunich> the VMs really bog it down, and its slow for place-and-route of FPGAs
[19:23:20] <jmkasunich> I would have been better off buying a notch better then - I bought the bargain stuff, and that probably took a year or so off (I was buying stuff that was "new" a year or more before)
[19:41:23] <alex_joni> I'm off to bed
[19:41:25] <alex_joni> good night all
[19:41:29] <jmkasunich> goodnight
[19:41:32] <skunkworks_> Night
[20:43:00] <christel> [Global Notice] Hi all, looks like one of our UK sponsors had a bit of a routing hiccup. Affected users ~2500. Normality should be restored momentarily. Thank you for using freenode and have a great day.
[20:54:33] <jmkasunich> hi jeff
[20:58:04] <jepler> hi jmkasunich
[20:58:11] <jepler> what's up?
[20:58:29] <jmkasunich> loose ends right now, later I want to work on FPGA stuff some more
[20:58:33] <jepler> ah
[20:58:48] <jepler> I see the check-ins when I have a chance to read my e-mail but I can't tell what shape things are in
[20:58:49] <jmkasunich> did you do any simulation of the pluto design?
[20:58:53] <jepler> no
[20:58:58] <jepler> I just crossed my fingers
[20:59:07] <jmkasunich> ghdl + gtkwave is a nice combo
[20:59:22] <jepler> for a short time I tried .. umm .. icarus verilog?
[21:00:35] <jmkasunich> with those progs and the makefile I've put together, simple simulations have about a 10 second cycle (from editor save command to waveforms on the screen)
[21:00:47] <jepler> when I was doubting the encoder index pulse I tried to do simulation of just that part, but as you may guess it didnt't show any problems
[21:00:53] <jepler> that sounds neat
[21:01:05] <jepler> any similar tools for verilog?
[21:01:08] <jmkasunich> I'm trying to make testbed vhdl programs for each chunk as I go along
[21:01:09] <jmkasunich> dunno
[21:01:33] <jmkasunich> * jmkasunich asks synaptic
[21:02:34] <jepler> well I'm being called away .. talk to you later
[21:02:41] <jmkasunich> ok
[21:02:42] <jepler> I'll actually be home again in 9 days or so
[21:02:49] <jmkasunich> enjoy the rest of the trip
[21:02:57] <jepler> thanks
[21:28:17] <skunkworks_> jmkasunich: do you have the link to the current sensing module that we had talked about a few months ago?
[21:30:12] <skunkworks_> failure to comunicate ;)
[21:30:17] <skunkworks_> communicate
[21:32:06] <jmkasunich> current sensing module... I'm afraid I'm drawing a blank
[21:32:09] <jmkasunich> hall effect things?
[21:32:25] <jmkasunich> there are lots of them out there, I dunno what I might have mentioned to you
[21:33:16] <skunkworks_> you had showed it to me for a solution for the amp. It had like 5,10,15 amp options depending on how it was wired.
[21:33:47] <jmkasunich> that sounds like a LEM LA0-25NP
[21:33:58] <jmkasunich> that sounds like a LEM LA-25NP
[21:34:20] <jmkasunich> google for that to get a datasheet (I don't have one here, I google when I need it)
[21:34:52] <skunkworks_> looking now - thanks
[23:46:20] <SWPadnos_> SWPadnos_ is now known as SWPadnos
[23:52:12] <SWPadnos_> SWPadnos_ is now known as SWPadnos
