Back
[08:24:16] <MarkX> morning
[08:43:37] <Lambda_Aurigae> it is morning..
[09:08:44] <MarkX> ...that it is...
[09:13:10] <twnqx> just where in the world is it morning at 10pm
[09:18:01] <Sevalecan> twnqx: that depends on where in the world it's 10pm at 10am...
[09:20:08] <twnqx> china :P
[09:20:31] <megal0maniac> Why is it such a pain to get Java to play nicely with serial comms?
[09:21:09] <twnqx> because whatever you do, it's a pain to get java playx nicely :D
[09:21:25] <megal0maniac> twnqx: You are correct. You win the prize.
[09:22:13] <megal0maniac> I need the simplest, dumbest front-end for a microcontroller application. My protocol is plaintext. You send a 1, it returns a \r\n terminated string with all the data.
[09:22:26] <megal0maniac> But Java just won't.
[09:22:58] <twnqx> set the stream to unbuffered?
[09:23:07] <twnqx> or manually flush it?
[09:24:46] <megal0maniac> twnqx: That's what I'm trying, once I figure out the code I already have :/
[09:25:10] <twnqx> not that i'd know more about java than "i wouldn't touch it" :P
[09:25:19] <twnqx> but it sounds a bit like some standard OS problems
[09:25:36] <megal0maniac> twnqx: I can get it to print to stdout
[09:25:55] <megal0maniac> But I want to call the function, and it returns a String.
[09:26:03] <megal0maniac> I'm probably asking too much :P
[09:26:46] <megal0maniac> Seems like the example just sits in an infinite loop of printing the buffer, which is usually empty.
[09:27:53] <twnqx> i kind of expected the problem being sendind the 1 to the µC
[09:31:48] <megal0maniac> Na, the library works pretty well in that regard. I can't find much/any documentation on it though, which is frustrating
[09:34:35] <megal0maniac> Anyway, I'll come back to this later. There must be API docs somewhere
[10:22:56] <Tom_itx> http://en.wikibooks.org/wiki/Serial_Programming/Serial_Java#Simple_Data_Transfer
[10:23:29] <Tom_itx> http://www.oracle.com/technetwork/java/index-jsp-141752.html
[10:25:04] * Tom_itx looks at megal0maniac
[10:34:13] <Tom_itx> http://www.java-samples.com/showtutorial.php?tutorialid=11
[10:38:21] <Tom_itx> https://henrypoon.wordpress.com/2011/01/01/serial-communication-in-java-with-example-program/
[10:38:39] <Tom_itx> surely one of those will do the trick
[10:45:53] <Jartza> java sounds like an overkill for app like that, I would use something like python
[11:03:58] <ferdna> why java...?
[11:04:08] <ferdna> i personally dont like java at all...
[11:12:13] <TechChristoph> Or c
[11:12:39] <TechChristoph> Maybe...
[11:23:32] <Lambda_Aurigae> bah...if you have linux you have built in serial terminals.
[13:15:39] <MarkX> quick question
[13:15:56] <MarkX> anyone know how to show a pad number when making a footprint in altium?
[13:16:14] <MarkX> in a video i'm watching the guy appears to have it on by default but I don't see the pad numbers on my screen
[13:28:31] <Tom_itx> nope
[13:28:36] <Tom_itx> can't afford altium
[13:32:18] <timemage> Tom_itx, what is it? like five grand?
[13:37:23] <Tom_itx> no idea but i know it's expensive
[13:40:35] <Tom_itx> they get students hooked on it then pull the plug once they're out
[13:42:21] <timemage> beeeeeeeeeeeeeep
[13:42:29] <MarkX> boop
[13:43:50] <aandrew> list price is $7500 and annual subscription is like $1200 after that
[13:43:59] <learath> youch
[13:44:13] <aandrew> yep. you can do better if you do the usual sales dance
[13:44:18] <aandrew> but not a whole lot better
[13:44:32] <timemage> yeah, that's what i need. a mortgage on my pcb cad program.
[13:53:02] <autrilla_> Do avrs have an unique serial number of some sort?
[13:53:28] <Tom_itx> i'm thinking there's a place you can assign one
[13:53:34] <Tom_itx> but not positive
[13:53:57] <autrilla_> Well, I was looking for some unique value for each chip that I didn't need to write in
[13:54:17] <autrilla_> I'm trying to have some kind of auto-addressing for an RS485 network
[13:54:22] <Tom_itx> i don't know then. you should ask abcminiuser when he shows up
[14:47:52] <Cykey> autrilla_: set one in the eeprom. Something like this:
https://ghostbin.com/paste/suonw
[14:48:05] <Cykey> The serial number will look like this: 689172FD50AD41C7
[14:48:26] <Cykey> then just use eeprom_read_block or something to access it from your code
[14:50:06] <autrilla_> Cykey, that doesn't guarantee uniqueness. If I have to write it to EEPROM, I'll make a shell script to check with a database and everything
[14:50:16] <Cykey> Yeah, you could do that
[15:12:15] <Lambda_Aurigae> autrilla_, no, no unique serial number in avr...most people who need that will write it to eeprom somewhere.
[15:22:23] <autrilla_> Lambda_Aurigae, mhm, writing it to the first block and then reading it shoudln't wear the memory out
[15:22:37] <Lambda_Aurigae> you can read infinitely.
[15:22:41] <Lambda_Aurigae> it's just writing that wears it out.
[15:23:35] <autrilla_> Now, how many bytes to use for the serial number :D
[15:23:45] <autrilla_> Each byte is two hex chars
[15:23:46] <Lambda_Aurigae> how many devices will you produce?
[15:23:52] <autrilla_> Lambda_Aurigae, that's a good question
[15:24:34] <autrilla_> For some of our devices we currently sell more than 500/year... But these devices will be much better, as they will all be in a network
[15:24:39] <Lambda_Aurigae> if you go 6 bytes you have the equivalent of ipv4 addresses.
[15:24:57] <Lambda_Aurigae> err.
[15:25:02] <Lambda_Aurigae> I mean, mac addresses
[15:25:11] <Lambda_Aurigae> 4 bytes for ipv4 address equivalence.
[15:25:12] <autrilla_> ipv4 is 4 bytes
[15:25:15] <autrilla_> yeah
[15:25:45] <autrilla_> Well, 4 bytes gives 4294967296 combinations
[15:25:53] <autrilla_> If we produce that many devices I might as well retire
[15:26:16] <Lambda_Aurigae> and 640K is more than enough ram for anybody!
[15:27:09] <autrilla_> I still have a lot of things to figure out, because multi-master multi-drop communication is a bit difficult
[15:28:01] <Lambda_Aurigae> multi-master i2c is doable.
[15:28:26] <autrilla_> limited to 8 devices right?
[15:28:29] <Lambda_Aurigae> or you can go CAN Bus.
[15:28:47] <Lambda_Aurigae> no...256 addresses on i2c.
[15:28:50] <Lambda_Aurigae> 8bit address.
[15:29:09] <Lambda_Aurigae> usually each device class or type has 3 bits selectable so you can run 8 of one kind on a bus.
[15:29:32] <Lambda_Aurigae> so, if you have PCF8574 8bit i2c port expanders, you can put 8 of them on the bus with your master device.
[15:29:37] <autrilla_> The range of I2C is very limited
[15:29:50] <Lambda_Aurigae> and if you add pcf8574A chips you can add 8 more.
[15:29:58] <Lambda_Aurigae> yes...2 or 4 meters, something like that.
[15:30:05] <Lambda_Aurigae> CAN bus is much longer I believe.
[15:30:31] <aandrew> CAN length varies with speed
[15:30:34] <aandrew> (as does RS485)
[15:30:43] <autrilla_> Rs485 can handle 1km
[15:30:45] <aandrew> I2C and SPI are intended to be short length
[15:31:34] <autrilla_> Also, RS485 is just the physical layer
[15:31:43] <Lambda_Aurigae> there are CAN enabled AVRs too.
[15:32:19] <aandrew> autrilla_: when you're talking "length of bus" you are already talking physical layer
[15:32:23] <autrilla_> Lambda_Aurigae, I'm using Arduino because it's easier for now, I'll port it later. In fact, I'll do it in Python with my computer first
[15:32:45] <autrilla_> aandrew, yes. But I want devices to be able to talk whenever they want, so I have to handle collisions etc
[15:33:02] <Lambda_Aurigae> aahh...python to arduino to ohgodhowdoyoudothisintherealworld!
[15:33:23] <autrilla_> Lambda_Aurigae, no, no. I'll design the protocol on Python and simulate it
[15:33:29] <aandrew> autrilla_: strongly recommend CAN over RS485 for that. it's all built-in to the MAC and PHY. You can certainly implement something similar on RS485 but it's not as nice
[15:34:37] <aandrew> CAN's design is specifically intended to be fault tolerant, multi-master, etc., etc. THe MAC hardware specifically operates to remove itself from the network if it can't seem to communicate
[15:34:53] <autrilla_> Lambda_Aurigae, and then porting from arduino to AVR shoudln't be that difficult. At some point arduino has to output AVR assembly
[15:35:11] <autrilla_> aandrew, is it much more expensive?
[15:35:30] <autrilla_> I did a bit of research about 6 months ago and I remember reading about it
[15:36:48] <aandrew> many microcontrollers (including AVR) have CAN controllers. The CAN PHY is not at all expensive
[15:37:24] <aandrew> basically instead of a UART talking to an RS485 transciever PHY, you have a CAN controller talking to a CAN PHY. you even get to use one less pin. (RS485 has RXD/TXD/DE, CAN just has RXD/TXD)
[15:37:44] <aandrew> CAN is a little odd to get your head around though... you don't just blindly send arbitrary data
[15:37:52] <aandrew> you have a message ID and up to 8 data bytes
[15:38:19] <autrilla_> only 8 data bytes?
[15:38:44] <Lambda_Aurigae> so you still have to have a PHY interface for the at90can chips I see.
[15:38:45] <aandrew> CAN is very much designed to be used in a "producer/consumer" data model where the various nodes transmit data and whoever's interested listens for it. You can absolutely use it differently (and in fact many implementations do) but it's just something to keep in mind
[15:39:00] <aandrew> autrilla_: it's not as big a deal as you think. think packets rather than arbitrary data
[15:39:01] <autrilla_> Using RS485 would mean creating my own protocol, so the protocol would adjust to my project, instead of having to adapt the project to the protocol. Anyway, making a protocol for RS485 would take time.
[15:39:25] <aandrew> if you really need arbitrarily long data you implement a fragmentation and reassembly mechanism which is what most things do
[15:39:42] <autrilla_> aandrew, well, yes - IP does that
[15:39:54] <aandrew> autrilla_: and you don't have to get fancy.
[15:40:23] <autrilla_> So, physically, the CAN bus is just a twisted pair?
[15:40:33] <aandrew> the CAN frames themselves already have CRC and you can get notified if a message fails to send or a message fails to ACK
[15:40:41] <aandrew> the CAN controller handles all of that as well
[15:40:49] <aandrew> so the CAN frames you receive are guaranteed to be good
[15:41:01] <aandrew> autrilla_: yep, 50-75 ohm twisted pair is typical
[15:41:50] <autrilla_> Mm, so maybe it's a good idea to use CAN. Breaking my data into packets (anyway, 8 bytes is more than enough for most stuff) is easier than making my own protocol
[15:42:45] <autrilla_> Basically, I'd want to get the value for a variable or set it. First packet provides set/get and what variable, if "set", second provides value
[15:42:48] <autrilla_> Easy peasy
[15:43:22] <Mr_Sheesh> Either an existing protocol or, if you're the only person on a bus, what I've done is to just use a plain text-ish protocol usually (something like D for data then ascii data then a non-ascii checksum byte and then CR/LF usually) - Quick and easy
[15:43:43] <Mr_Sheesh> But if already in a CAN framework, makes sense to use that!
[15:44:08] <autrilla_> Mr_Sheesh, we'd be the first ones to do this in our sector
[15:45:04] <Mr_Sheesh> Think sorta carefully then? As you can be the person people all point at and mutter under their breath, otherwise? :P
[15:45:55] <autrilla_> Even if it works fine it doesn't mean people will buy it
[15:46:28] <autrilla_> We see it as something that's needed, because having to go to a farm to monitor the devices there is a pain in the butt
[15:46:32] <autrilla_> Easier done from home
[16:12:49] <tpw_rules> autrilla_: can also has remote transmit request where you can ask a remote node to retransmit a message
[16:13:26] <tpw_rules> how can usually works is things like sensors are broadcast every so many milliseconds and if you need the data, you can send an RTR to get it now. if you want to tell somebody something, you broadcast it and they listen for it
[16:13:28] <MarkX> N1njaneer: pping?
[16:13:30] <autrilla_> tpw_rules, why would I want to do that if the message arrived fine?
[16:14:05] <tpw_rules> it typically works like each sensor is broadcast, say, every 100ms
[16:14:22] <tpw_rules> if you need the value of a sensor NOW for some reason, you send an RTR to that id and it will get transmitted again immediately
[16:15:04] <autrilla_> Well, I don't only have sensors. I have machines too. For example, a window controller and a temperature probe
[16:15:37] <tpw_rules> you have to remember CAN is a broadcast system. the only (can-provided) tag is a message ID which every node on the network hears
[16:16:11] <autrilla_> Doesn't CAN do addressing?
[16:16:29] <tpw_rules> no. you cannot talk only to a specific device. everybody will hear you
[16:17:11] <tpw_rules> your temperature probe might broadcast with a message id meaning temperature and the data with a probe id and temperature
[16:17:25] <tpw_rules> your window controller will still hear this and it must decide that it doesn't care about that message id
[16:17:44] <autrilla_> Mhm, so I'd still have to implement some protocol logic
[16:18:11] <tpw_rules> can controllers can usually have filters on them
[16:18:12] <autrilla_> CAN will handle collisions and transmission errors basically
[16:18:18] <tpw_rules> yes
[16:18:26] <tpw_rules> it also has arbitration
[16:18:38] <tpw_rules> so any message with a lower ID will get automatically transmitted over one with a higher ID
[16:18:41] <autrilla_> Still, for roughly the same cost, I'd have to do less work
[16:18:55] <tpw_rules> you could put a fire alarm on ID 1 and nobody else can talk over it
[16:18:55] <tpw_rules> yes
[16:19:07] <tpw_rules> but can isn't like RS-232/485 where you can just blast bytes out willy-nilly
[16:19:30] <autrilla_> I don't want to do that. The protocol I was thinking of making was packet-based
[16:19:52] <autrilla_> Packets could range from 0-256 bytes, so that's a bit better than CAN
[16:19:54] <tpw_rules> you must give thought to message IDs and who will hear what. if you have a large amount of devices, you may need to have multiple networks or a faster network or messages transmitted less often
[16:20:02] <tpw_rules> disclaimer: i know CAN from how it's implemented in automobiles
[16:20:23] <autrilla_> How many devices is a large amount?
[16:20:38] <tpw_rules> in theory, you could have message id = destination, and your 8 bytes be whatever they want
[16:21:07] <tpw_rules> depends on how often they must transmit
[16:21:29] <autrilla_> 10 seconds, maybe
[16:21:53] <tpw_rules> oh no you can put everything on one
[16:22:17] <autrilla_> Oh, yeah, if CAN doesn't do addressing it'll make it difficult... I'd like addressing to be kind of automatic
[16:22:37] <autrilla_> I though about using serial numbers as ids, but with 8 bytes per packet, I'd only have 4 bytes left for data
[16:22:44] <tpw_rules> well it can (haha). the MCP2515 SPI can controller has filters in it
[16:23:05] <autrilla_> What is the message id exactly?
[16:23:13] <autrilla_> An arbitrary ID for each message?
[16:23:26] <tpw_rules> in automobiles, it usually means the source of the message
[16:23:36] <tpw_rules> it's integrated into can and factors into arbitration
[16:24:01] <tpw_rules> if two devices try to talk at the same time, the one with the lower message id will get heard. this is due to how the signaling works
[16:24:38] <autrilla_> Mhm, so I could prioritize more important devices giving them lower serial numbers. How big is the message id?
[16:24:38] <tpw_rules> if they have the same message id, the messages will be logically ANDed with each other
[16:24:47] <tpw_rules> 11 bits regularly, or 29 bits for an extended frame
[16:25:13] <tpw_rules> the MCP2515 supports both
[16:25:45] <autrilla_> 11 bits gives me just 2048 serial numbers, I'd expect to sell more than that
[16:26:06] <autrilla_> 29 gives ~600 million, that'd be enough
[16:27:18] <tpw_rules> the MCP2515 can filter messages out based on their ID and only interrupt you for ones you care about
[16:27:38] <tpw_rules> you can also filter based on bytes 0 and 1 in the message
[16:28:19] <tpw_rules> can you tell me again what you are planning to do?
[16:29:10] <autrilla_> tpw_rules, of course. We manufacture livestock equipment, some of it electronic, to control things on farms. For example: fans, opening and closing windows, opening an electrovalve....
[16:29:21] <tpw_rules> yes
[16:29:25] <autrilla_> Currently, a worker has to be in the farm operating those devices.
[16:29:44] <tpw_rules> like by flipping a switch or do you have some sort of pre-existing electronic control?
[16:30:02] <autrilla_> tpw_rules, we use Microchip microcontrollers
[16:30:13] <tpw_rules> well how are they controlled now?
[16:30:33] <autrilla_> For example, our window controller lets you set max window height, min window height, desired temperature...
[16:30:50] <tpw_rules> but how? is there a panel on it or is it already able to be controlled remotely?
[16:30:54] <autrilla_> But, if you want to see the height the windows are currently at and the temperature, you have to go to the farm
[16:30:59] <autrilla_> tpw_rules, there's a panel on it
[16:31:09] <tpw_rules> oh, okay
[16:31:50] <autrilla_> Also, everything on farms nowadays is isolated
[16:32:11] <tpw_rules> i don't know what that means
[16:32:27] <autrilla_> They don't know about other devices. Combining more devices for controlling temperature, for example, could be more efficient
[16:35:09] <tpw_rules> i agree with can because it has an excellent phy layer, but working with it might be a bit difficult. the issue is that if multiple messages with the same ID happen to be transmitted at the same time, they will be corrupted
[16:35:22] <tpw_rules> you'll hear about it from the controller, but they will not have gotten through
[16:37:06] <autrilla_> tpw_rules, so, basically, if I want more control, I should use RS485 with my own protocol. I will look at how CAN detects collisions and errors in messages and see how hard it'd be to do it myself.
[16:37:23] <tpw_rules> first, can has a simple checksum to detect errors
[16:37:41] <autrilla_> I planned on using CRC
[16:37:47] <tpw_rules> the can phy is effectively open-collector, so a 0 is dominant and 1 is recessive
[16:38:18] <tpw_rules> if a can controller hears back a 0 and it was transmitting a 1, it assumes it got arbitrated over and it shuts up
[16:38:49] <autrilla_> It just stops transmitting?
[16:38:53] <autrilla_> Doesn't it resume later?
[16:38:55] <tpw_rules> it is also mandatory that the controllers take themselves off the network if they have certain amounts of receive or transmit errors
[16:38:59] <tpw_rules> well for that message
[16:39:10] <tpw_rules> and wait a while before rejoining
[16:39:21] <autrilla_> As I see it CAN is more for stuff intended to be transmitting every X time
[16:39:25] <tpw_rules> it is
[16:40:56] <autrilla_> And CAN uses the physical layer directly to avoid collisions. I can't do that, but on RS485 collisions just corrupt messages, so the CRC check would fail
[16:41:03] <autrilla_> Maybe I don't really need to check for collisions
[16:41:24] <tpw_rules> and whatever wants the transmitted information will listen and act upon it
[16:41:45] <tpw_rules> i would recommend CAN honestly. because they've all figured this stuff out and there aren't any edge cases to screw you up
[16:41:56] <tpw_rules> you send messages and they arrive, and you receive messages that others sent
[16:42:22] <tpw_rules> the only real limitation is that message IDs should be unique for each device because otherwise you could corrupt messages
[16:42:42] <autrilla_> tpw_rules, so I could have the message ID be the target device, for example
[16:43:12] <tpw_rules> well if you want what a device transmits, you could send the ID as a remote transmit request, which asks the device to send out whatever it would normally broadcast on that id
[16:43:39] <autrilla_> And then, 4 bytes of the packet be the sending device, then the other 4 bytes the "command", and then as many parameters as I want on other packets.
[16:44:05] <tpw_rules> you'd want the message ID to be the sending device
[16:44:12] <tpw_rules> also btw, if you get a can FD controller, you can have 64 byte message
[16:45:51] <tpw_rules> the message ID pretty much always needs to be the source device
[16:45:58] <tpw_rules> that has to be unique across the netowrk
[16:46:14] <autrilla_> tpw_rules, but if the message ID is the sending device, I have to send everything I want to send in one packet
[16:46:32] <tpw_rules> but you could for example have the first bit of the first byte be 1 if this is a regular broadcast, or a 0 if this is a command
[16:46:41] <tpw_rules> if it's a command, then the next three bits might be a chain ID
[16:47:15] <tpw_rules> it's possible to guarantee message delivery, so you wouldn't need to worry about dropping messages in a chain
[16:48:02] <autrilla_> tpw_rules, what do you mean by chain ID? Something to specify that the device isn't done transmitting?
[16:48:06] <tpw_rules> yeah
[16:48:12] <tpw_rules> wait for more and put it in a buffer
[16:48:21] <tpw_rules> or you could upgrade to can FD, which supports 64 byte frames
[16:48:41] <tpw_rules> it's also compatible with existing CAN frames so if a controller doesn't support it, it will just ignore the message
[16:49:02] <autrilla_> 8 bytes are probably enough if I chain messages
[16:49:32] <tpw_rules> honestly, phy will be easy with can
[16:49:39] <tpw_rules> just remember the 120 ohm terminating resistor
[16:50:05] <autrilla_> You also need a terminating resistor on RS485 don't you?
[16:50:11] <tpw_rules> i dunno
[16:50:20] <tpw_rules> i'm just saying i forget it in test networks and then things break and i cry
[16:50:47] <tpw_rules> anyway, i gotta go. seriously do can
[16:50:54] <autrilla_> I have to go too
[16:50:57] <autrilla_> I'll do can, yes
[16:51:03] <autrilla_> See you and thanks!
[17:02:58] <aandrew> yes, you typically want termination no matter what
[17:03:10] <aandrew> ideally you match it to your cable
[17:03:24] <aandrew> low speed is pretty forgiving though
[17:04:25] <aandrew> you need to put some thought into your message IDs. lower message IDs have precedence on the bus; if two transmitters start transmitting at the same time the one with the lower ID wins (this is called arbitration)
[17:07:40] <aandrew> so if you say msgid 0x101 = send data and msg id 0x100 = ack data (this is how most things bastardize the idea of CAN)
[17:07:57] <aandrew> that way an ACK makes it through if a command and ack happen at the same time
[17:19:36] <aandrew> if you really need longer messages you could dedicate a group of 16 message IDs and encode the fragment number within the low 4 bits
[17:20:56] <aandrew> so let's say msg id 0x100 through 0x10f would be message 0x10, with up to 128 bytes of payload (id 100 = first block, 101 = second, etc.) and maybe a final RTR frame of 0x110 which the receiver can say "got it all" or "error"
[17:21:00] <aandrew> anyway lots of ways to do it
[17:27:52] <LeoNerd> Eagle question: anyone know if/how I can tell the board layout to ignore a particular component that's in the schematic? I have an extra connector on there that I don't actually want to place on the board
[17:45:03] <aandrew> LeoNerd: not really no
[17:45:08] <aandrew> is anyone here using eagle on osx?
[18:12:32] <malinus> Hello, what does "int const * Ptr" mean? I know what "const int * Ptr" and "int * const Ptr" means though.
[18:30:47] <timemage> malinus, the first two forms are functionally identical.
[18:32:13] <timemage> malinus,
http://www.slack.net/~ant/cpp/const_style.html <- someone's opinion regarding placement of the keyword.
[18:33:45] <malinus> timemage: ah, thanks
[21:23:53] <brabo> phew
[21:24:13] <brabo> finally got decent networking on the xmega with enc28j60
[22:44:15] <rootB> hey AVR
[22:44:19] <rootB> anyone here has used an ISA BUS?
[22:44:37] <Tom_itx> rue has
[22:44:42] <rootB> really?
[22:44:44] <rootB> Can i talk to him?
[22:44:48] <Tom_itx> as a programmer?
[22:45:04] <Tom_itx> rue_house can rootB talk to you?
[22:45:05] <rootB> as a student who needs help
[22:48:17] <Casper> rue tend to lag by a few hours sometime
[22:50:47] <rue_house> rootB, what do yo uwant to do?
[22:51:20] <rootB> Ok, the situation is the following: My teacher is teaching us how to use the ISA bus in our computer interface class (basically he's old school which means he teach us old tech.)
[22:52:42] <Valen> dunno, starting on isa is probably still not a terrible idea, trying to lay out a PCB to pass PCI-E would be interesting ;-P
[23:15:21] <Casper> hey rue_house... do you have an idea how to deal with a manufacturer that refuse to honor their waranty of 10 years on a dropamp?
[23:17:42] <rue_house> throw it thru their window (main office)
[23:19:24] <Casper> that wouln't be too hard
[23:19:30] <Casper> it's in monteal :D
[23:20:48] <Casper> I guess I'll have to threaten them with legal stuff...
[23:22:36] <learath> the isa bus or the dropamp?