Back
[00:38:38] <rue_shop5> anyone awake?
[00:38:56] <rue_shop5> something in my code cuases the reset not to be driven nicely anymore
[00:39:10] <rue_shop5> I recovered my chips with a wire jumper
[00:39:32] * Casper looks at rue_shop5 and laught, then go to bed
[00:39:33] <Casper> nite
[00:39:33] <Casper> :D
[00:40:31] <rue_shop5> http://paste.debian.net/686981/
[00:40:37] <rue_shop5> really simple code, I cant see the problem
[00:41:28] <rue_shop5> AND it keeps transmitting 0xB8, which shouldn't even be possable
[00:52:47] <cehteh> rue_bed: mwahaha :D
[00:53:11] <cehteh> rue_shop5: ... wtf how many nicks do you have
[00:55:14] <cehteh> your b00.. macros are suspicious and PORTB = b011; PORTB = b010 .. is that really what you want to do? change within once cpu cycle?
[00:55:52] <cehteh> actually one cpu cycle isnt guranteed (the value needs to be loaded in one register)
[00:56:33] <rue_shop5> yup
[00:56:49] <rue_shop5> its not too fast, I tested it
[00:57:13] <rue_shop5> I just had it send(p) instead of the lookup and the count is correct
[00:57:26] <rue_shop5> but that table code always results in 0xB8
[00:58:36] <rue_shop5> a 32 byte lookup table shouldn't perplex a t13
[00:59:23] <rue_shop5> and that code causes the programmer not to be able to reset the t13 for programming
[00:59:48] <cehteh> huh?
[01:00:30] <rue_shop5> chip is fine, I program it with that code, and it wont program again, until I jump the reset to ground just as its trying to program it
[01:00:56] <rue_shop5> if I put other code on it, its fine repeatedly
[01:01:18] <cehteh> you didnt set the rstdisbl fuse?
[01:01:20] <rue_shop5> I would expect that if I set the reset pin (PB5) high as an output
[01:01:27] <rue_shop5> its defalt
[01:01:56] <rue_shop5> and, as I said, if I jump the reset to ground it'll program
[01:02:06] <cehteh> strange
[01:02:07] <rue_shop5> (briefly as avrdude tries to program it)
[01:02:29] <rue_shop5> I'm sure nothing there sets PB5 to an output
[01:03:42] <cehteh> btw you want to make the table static
[01:04:55] <rue_shop5> I just changed the definition
[01:05:01] <rue_shop5> const unsigned char table[] = { 0x44, 0x35, 0x26, 0x17, 0x07, 0x97, 0xA6, 0xB5, 0xC4, 0xD3, 0xE2, 0xF1, 0xF0, 0xF9, 0xEA, 0xDB, 0xCC, 0x8D, 0xAE, 0x9F, 0x0F, 0x1F, 0x2E, 0x3D, 0x4C, 0x5B, 0x6A, 0x79, 0x70, 0x71, 0x62, 0x53 };
[01:05:23] <rue_shop5> and defined it globally
[01:05:49] <cehteh> the first send(0) comes through?
[01:06:11] <rue_shop5> I'm looking at it on an analog scope
[01:06:15] <rue_shop5> so, no idea
[01:06:30] <cehteh> try send(0xaa)
[01:06:44] <rue_shop5> I did send(p) and it worked
[01:07:00] <rue_shop5> I can see the 5 bit count
[01:07:59] <cehteh> what is that going to do?
[01:08:16] <rue_shop5> it controls an SLA7044 stepper driver
[01:08:25] <cehteh> im mean you send at a extremely fast and undefined rate
[01:08:39] <cehteh> everything the compiler does affects it
[01:08:42] <rue_shop5> the min timing is 150ns
[01:08:48] <cehteh> lockup into the table already
[01:09:10] <cehteh> i'd add some more predictable timing
[01:09:31] <cehteh> how fast is the avr running?
[01:09:31] <rue_shop5> the avrs timing is 1.5us
[01:09:35] <rue_shop5> 1Mhz
[01:09:46] <rue_shop5> so that bit is comming out ok
[01:09:58] <rue_shop5> its in spec
[01:10:18] <cehteh> but as soon you use the table its off?
[01:10:32] <cehteh> look at the assembler it generates
[01:11:06] <rue_shop5> ok changing the table to a globally defined const worked
[01:11:24] <rue_shop5> but its still got the reprogramming issue
[01:12:02] <cehteh> maybe the int0 blocks it? .. read datasheet, iirc the INTx isr's have some special properties
[01:12:24] <rue_shop5> on the programming baord, there is no int0 trigger
[01:13:05] <rue_shop5> I have another program that uses int0 and there are no issues
[01:13:49] <rue_shop5> I'd swear it started screwing up when I changed the polarity of the 3rd bit in the latch() definition
[01:18:44] <rue_shop5> ok, there is life
[01:18:49] <rue_shop5> lots of thigns to resolve yet
[01:19:09] <rue_shop5> the datasheet twisted the values of the table around on me, so i have to rewrite it
[01:24:14] <rue_house> so the bits are backwards and shifted right one place...
[02:15:53] <rue_shop5> OH YEA, got it
[02:16:01] <rue_shop5> damn that drives 'em good
[02:16:12] <rue_shop5> ok, I need to bump it to 4.8Mhz tho
[02:16:36] <rue_shop5> / Set clock prescaler: 0 gives full 4.8 MHz from internal oscillator.
[02:16:36] <rue_shop5> CLKPR = (1 << CLKPCE);
[02:16:36] <rue_shop5> CLKPR = 0;
[02:23:08] <rue_shop5> haha I flashed the wrong firmware to the chip
[02:24:27] <rue_shop5> at about 20K steps/sec the motor cant keep up
[02:24:29] <rue_shop5> SWEET
[02:26:51] <rue_shop5> haha I got it up to 45k, which is where the irq stops responding
[04:12:39] <l9> oh my mother of a sweet child i am sick of python, maybe i should buy a audrino
[04:17:15] <dunz0r> l9: They're quite good for dev-boards for avr-projects
[04:17:34] <dunz0r> And you can write glorious AVR-C on them instead of Arduino-C++ if you like
[04:20:56] <skz81> or even AVR-C++ ^^
[04:21:12] <l9> what board should i get?
[04:23:19] <dunz0r> l9: The Uno imho. It has got an Atmega328 on it and those are nice to work with
[04:23:42] <skz81> l9, depends of what you want to do, arduino uno r3 (or a clone, but beware of what chip of have for serial USB)
[04:32:33] <l9> arduino uno r3 atmega328P it is then
[04:42:22] * twnqx would go lenoardo for true USB playground
[04:42:28] <twnqx> leonardo*
[04:44:11] <dunz0r> Yeah, the leonardo's really fun as well.
[04:44:25] <skz81> l9 atmega328 and 328p are nearly the same, plus some power saving features IIRC
[04:44:32] * dunz0r built a 47-key usb matrix with his leonardo
[04:46:47] <Jartza> I ordered 10 atmega328pb mcus
[04:46:52] <Jartza> wanna try them out
[04:47:04] <twnqx> pb? do they have extra lead in them?
[04:48:05] <dunz0r> Jartza: They're great, love 'em :)
[04:48:18] <dunz0r> Has all the features you'd ever want in an µCU
[04:57:59] <Jartza> well, that I don't believe, but yea, look nice alternative for 328p
[04:57:59] <Jartza> :)
[05:20:03] <Jartza> depends of the need, of course
[05:20:16] <Jartza> in many cases attiny85 has proven to have all the features I need ;)
[12:57:23] <LeoNerd> Mistakes I always make: managing to swap SDA and SCL in at least one place somewhere on the board
[12:57:38] <LeoNerd> Fortunately this was right in the header for a connector socket, so I can just swap the pins
[13:12:46] <rue_shop5> tiny13 anyone know pitfalls that screw up programmers that dosn't involve the reset pin control fuse?
[13:29:00] <RikusW> rue_shop5: Hi
[13:29:24] <RikusW> do you know how to set channel permissions to only allow registered users ?
[13:30:01] <LeoNerd> +R ?
[13:30:51] <RikusW> will check that out thanks
[13:31:24] <RikusW> +R on what ?
[13:31:40] <RikusW> flags -> +R - Enables use of the recover, sync and clear commands
[13:33:13] <antto> RikusW r u gonna put this on this channel?
[13:33:32] <RikusW> I'm not an op here
[13:33:42] <antto> k
[13:34:00] <RikusW> Have any of you worked on AVB before ?
[13:36:39] <Casper> rue_shop5: someone years ago said that you can still control the DDR, PORT and PIN on some avr where the reset pin is reusable, allowing to create a software reset function...
[13:36:56] <Casper> if not, have you forgot the pullup on the board?
[13:37:28] <antto> RikusW +r would prevent UFOs from joining
[13:37:51] <antto> there's also a quiet mode which can be used to only prevent them from talking on the channel
[13:38:58] <LeoNerd> Casper: Mmm.. that can go wrong though. Ideally you need to hold RESET down for long enough, but the moment it starts the chip puts HiZ on all pins
[13:39:07] <LeoNerd> So sometimes it doesn't generate a long-enough pulse
[13:40:59] <RikusW> antto: +b is even better :-P
[13:42:46] <antto> +b *!*@* ftw
[13:44:25] <RikusW> what does that do ?
[14:08:31] <antto> RikusW >:)
[14:08:58] <RikusW> ban us all ?
[14:09:09] <antto> bans by hostmask, and that particular hostmask matches pretty much all users ;P~
[14:50:51] <daey> i just realized... can i replace a PORTB = 0xFF; with a char *ptr; ptr->0xXXXX = 0xFF; ?
[14:56:57] <LeoNerd> Ughhh *groan*
[14:57:11] <LeoNerd> mega32U4 has one UART. It is number 1. Not number 0 like every other AVR chip
[14:57:19] <LeoNerd> ... so now my generic uart.c doesn't like it. :/
[14:57:24] <liwakura> daey: if you have a giant io struct, yes
[14:57:41] <liwakura> but ig you have a char
[14:57:46] <daey> liwakura: what do you mean with gian io struct?
[14:57:51] <daey> i mean just what i wr ote there
[14:58:14] <liwakura> make ptr a struct with contains all i/o registers as elements, so you can use ptr->0xXXXX
[14:58:44] <LeoNerd> liwakura: I dislike that.. compiletime-known register fiddling turns into nice efficient IO instructions
[14:58:46] <daey> so i cant just point a pointer to a specific register?
[14:58:52] <liwakura> daey: you can
[14:58:59] <LeoNerd> Oh.. that wasn't to me ;)
[14:59:09] <liwakura> with char *pt = 0r; ptr[0x37] = 0xFF; ?
[14:59:23] <liwakura> no "->" syntax
[14:59:27] <liwakura> or am i wrong?
[15:01:39] <daey> well the idea came up because i found this in an arm code example "GPIOD->MODER |= mode;"
[15:02:24] <liwakura> daey: if you read the io.h file, you'll notice that stuff like PORTB is actually just *(addr of PORTB)
[15:02:37] <LeoNerd> daey: That works great on Xmega because of the more uniform peripheral layouts
[15:02:45] <LeoNerd> Doesn't work so well on ATmega because they're all messy
[15:03:06] <liwakura> yeah
[15:03:14] <liwakura> the atmegas dont have i/o structs by default
[15:03:44] <GeneralStupid> yes i did some work on openrisc (baremetal) and this PORTB stuff is really nice in some way
[15:03:55] <daey> so i can write *(0xXXXX) = 0xFF;?
[15:04:05] <liwakura> daey: yes.
[15:04:42] <daey> interesting. but it doesnt seem to work with the standard gcc
[15:04:58] <liwakura> type error i guess
[15:05:12] <daey> error: invalid type argument of unary ‘*’ (have ‘int’)
[15:05:22] <liwakura> try *((char *)0xXXXX) = 0xFF;
[15:05:43] <daey> yeah that works
[15:05:50] <liwakura> lol derp im a C guru
[15:05:52] <daey> but why
[15:06:02] <daey> does a pointer expect a char?
[15:06:06] <daey> that sounds odd
[15:06:08] <liwakura> no
[15:06:17] <daey> a char* to be precise
[15:06:19] <liwakura> "char *" means "pointer to char"
[15:06:40] <liwakura> so, it justs expects some sort of pointer you can dereference and assign 0xFF to
[15:07:05] <liwakura> maybe it wont work using a voidpointer
[15:07:23] <daey> int * works as well
[15:07:45] <liwakura> uhm, but then it will write sizeof(int) bytes to that address
[15:07:53] <liwakura> which is 2 on many AVR's
[15:08:33] <liwakura> if not on all
[15:08:59] <daey> makes sense
[15:10:07] <liwakura> if you feel like it you can make a for(ptr = (char*)0; ptr++; ptr <= (char*)RAMEND) dump_byte(ptr);
[15:10:18] <liwakura> implement dump_byte yourself
[15:10:49] <liwakura> this would print all i/o registers contents (including all the sideeffects reading them has) and the memory contents
[15:12:23] <liwakura> you could also write 0xFF to all of them, i don't know how badly this will fuck up your device
[15:23:08] <rue_shop5> Casper, just incase, I dropped the reset pullup from 1k to 10k
[15:23:34] <rue_shop5> I'm pondering the possability that the programmer was just on the virge of being able to pull it low
[15:23:46] <rue_shop5> I"ll test in 6 seconds
[15:23:58] <rue_shop5> nope
[15:24:23] <rue_shop5> it makes developing this software a real pain in the ass
[15:24:34] <rue_shop5> good thing its working
[15:24:52] <rue_shop5> oops I just flashed the wrong version
[15:24:59] <rue_shop5> did I mention the pain in the ass part?
[16:29:12] <LeoNerd> So.. I have a 32U4 breakout board, that avrdude keeps giving me 'verification error' on. Always same address, 0x7000, always a single bit that's stuck 0 when it should be 1.
[16:29:15] <LeoNerd> Same bit every time
[16:29:24] <LeoNerd> Can anyone think of any reason other than "the flash cell is dead" for this?
[16:33:04] <LeoNerd> Oh wait a moment... that -might- be because bootloader
[16:33:23] <LeoNerd> Isn't 0x7000 the start of bootloader space?
[16:33:40] <LeoNerd> I'm programming it via onboard avr109 thingy via USB, so that might be it
[16:38:30] <bss36504> I actually have about 100 32U4s that had different (yet individually consistent) memory problems. Bought them from Newark.
[16:38:44] <bss36504> Granted, I tested about 10 of them then just bought more.
[16:39:16] <bss36504> The new ones I bought worked fine on the same exact board as each the failures.
[16:40:51] <LeoNerd> Mmm.. Maybe I just have a weird chip
[18:22:14] <goddard> when i send data via uart from my teensy i get it on my system and the characters are always "\xFE" or "\xFF"
[18:22:59] <liwakura> goddard: probably speed mixup, when you system is muuuuch slower than your teensy
[18:24:28] <goddard> liwakura: hmm i have them set the same
[18:24:30] <goddard> USART_BAUDRATE 500000
[18:24:34] <liwakura> i mean your uart speed, not the system speed or clock
[18:25:17] <goddard> ok i will check
[18:25:58] <goddard> liwakura: oh that was it
[18:26:01] <goddard> thanks man
[18:26:51] <liwakura> i feel like a skilled person right now
[18:27:27] <liwakura> goddard: random fact: Basshunters's song "Boten Anna" is about an IRC Bot named "Anna"
[18:28:42] <liwakura> goddard: also, usually not all possible baud rates are supported
[18:28:42] <liwakura> i'd recommend to use a standart one like 9600 or 115200 baud
[18:28:42] <liwakura> *standard
[18:29:48] <goddard> ok
[18:31:45] <goddard> what do you do if you get mixed signals like
[18:31:47] <goddard> T
[18:31:50] <goddard> est String
[18:31:57] <goddard> intstead of "Test String"
[18:32:16] <goddard> Do you just watch for stuff character by character?
[18:32:35] <Lambda-Aurigae> send UUUUUUU about 500 times and see if you get anything strange.
[18:32:52] <Lambda-Aurigae> how are you connecting your avr to the PC?
[18:33:14] <Lambda-Aurigae> are you using built in usb-serial something or an external usb-serial adapter or a real serial port?
[18:34:46] <goddard> I am using my teensy out via UART to another UART device TX/RX signal and that device is connected via USB
[18:35:09] <Lambda-Aurigae> and what is the teensy's clock frequency? and what is your uart speed?
[18:35:40] <goddard> my teensy is connected 500000 and my program is 500000
[18:38:06] <Lambda-Aurigae> what is the teensy's cpu clock speed?
[18:38:14] <goddard> let me check
[18:39:32] <goddard> atmega32u4
[18:39:48] <Lambda-Aurigae> that tells me squat.
[18:40:00] <Lambda-Aurigae> it is running with an external crystal..what is the frequency of that crystal?
[18:40:38] <goddard> says default is 2Mhz
[18:40:53] <Lambda-Aurigae> I seriously doubt that if it uses the onboard usb for anything.
[18:41:03] <Lambda-Aurigae> it is going to be 12, 16, or 20 most likely.
[18:41:13] <Lambda-Aurigae> which teensy is it?
[18:41:37] <goddard> 2.0
[18:41:48] <Lambda-Aurigae> that runs at 16MHz
[18:41:55] <goddard> oh
[18:42:03] <Lambda-Aurigae> https://www.pjrc.com/teensy/
[18:42:15] <goddard> what is this
https://www.pjrc.com/teensy/prescaler.html
[18:42:17] <goddard> ?
[18:43:05] <Lambda-Aurigae> if you are prescaling it to 2MHz then your bit error rate is 50 to 75 %
[18:43:24] <Lambda-Aurigae> that prescale command allows you to slow down the processor.
[18:44:00] <Lambda-Aurigae> at 2MHz processor speed the bit error rate for the UART with U2Xn set to 0 is -75%
[18:44:28] <Lambda-Aurigae> you will get lots of errors in the transmission at that speed.
[18:45:09] <Lambda-Aurigae> I see...
[18:45:24] <Lambda-Aurigae> that teensy does default to 2MHz with a hefty prescaler turned on...my fault there.
[18:45:27] <goddard> ahh
[18:45:31] <Lambda-Aurigae> but, that is kinda silly.
[18:45:36] <Lambda-Aurigae> rather stupid even.
[18:45:55] <Lambda-Aurigae> but, still, it won't communicate at 0.5Mb/s at 2MHz clock speed.
[18:46:20] <Lambda-Aurigae> not unless you are connecting to another device of the same type that is configured the same way.
[18:46:51] <Lambda-Aurigae> I'm surprised it communicates at all.
[18:47:03] <goddard> im not doing that i just thought that was the clock speed
[18:47:07] <goddard> i didn't set it mysellf
[18:47:13] <goddard> that is why i didn't know
[18:47:28] <goddard> i just set the baud rate which i left out a zero and that was why i was getting bad data
[18:47:45] <Lambda-Aurigae> seems you are still getting bad data.
[18:48:04] <Lambda-Aurigae> I would try a bit rate that your chip at its actual running speed will support.
[18:48:53] <Lambda-Aurigae> http://wormfood.net/avrbaudcalc.php
[18:48:55] <goddard> yeah not as bad at least the i can see the characters
[18:49:47] <goddard> maybe things are just a little off?
[18:49:50] <Lambda-Aurigae> without knowing how that teensy is actually set there is no way for me to really figure out why you are getting random bad data.
[18:50:11] <Lambda-Aurigae> but I'm betting your clock speed is wrong for your bit rate and you have a pretty high bit error rate because of it.
[18:50:36] <goddard> That is why i get a
[18:50:38] <goddard> T
[18:50:41] <goddard> est String
[18:50:48] <Lambda-Aurigae> possibly.
[18:51:28] <Lambda-Aurigae> need to eliminate things...and to eliminate there being a bet error rate problem you need to know the cpu clock speed and the settings for the USART..what is the UBRR, what is the U2Xn bit set to?
[18:52:12] <goddard> im new to this stuff man i dont know
[18:52:27] <goddard> let me try and find it
[18:52:42] <Lambda-Aurigae> well, if the teensy defaults to 2MHz and you haven't changed it and are not setting any prescaler configuration then it is running at 2MHz
[18:52:55] <Lambda-Aurigae> then you need to figure out how it is calculating the UBRR.
[18:53:01] <Lambda-Aurigae> that is in the code somewhere.
[18:53:24] <Lambda-Aurigae> then you need to see if U2X0 or U2X1 or U2X is set to 1 anywhere in the code.
[18:53:52] <Lambda-Aurigae> I would recommend reading the datasheet but people around here punch and kick and pinch me when I suggest things like that.
[18:56:03] <goddard> Lambda-Aurigae: my UART device is a CP2102
[18:56:16] <Lambda-Aurigae> I meant the USART on the AVR
[18:57:32] <Lambda-Aurigae> the CP2102 is a USB to Serial adapter chip.
[18:57:37] <goddard> yeah
[18:57:53] <goddard> its what i send the signal through to the teensy
[18:58:07] <Lambda-Aurigae> the teensy has a USART built into the AVR.
[18:58:22] <Lambda-Aurigae> that USART has to be configured somehow.
[18:58:31] <Lambda-Aurigae> it's that configuration that I have been talking about.
[18:58:52] <Lambda-Aurigae> the AVR is the processor on the teensy.
[18:58:57] <Lambda-Aurigae> it has to be programmed.
[18:59:34] <goddard> yeah
[18:59:59] <goddard> i connected the uart adapter chip on tx/rx to teensy d2/d3
[19:02:21] <goddard> Lambda-Aurigae: ok so my make file has F_CPU = 16000000
[19:03:34] <Lambda-Aurigae> so the makefile thinks it is 16MHz
[19:03:38] <Lambda-Aurigae> that doesn't make it so.
[19:03:52] <Lambda-Aurigae> according to the thing you posted earlier you have to change the prescaler in the code to make it so.
[19:04:51] <Lambda-Aurigae> I'm guessing that as it is talking at all that it is set to 16MHz with the prescaler in the code somewhere.
[19:05:28] <Lambda-Aurigae> otherwise with F_CPU set like that the baud rate calculations would just not work at all.
[19:05:47] <Lambda-Aurigae> I would recommend dropping down to 9600 bits per second and see if you get stable communications.
[19:05:57] <goddard> alright ill look further
[19:06:15] <goddard> im using the LUFA library
[19:06:24] <Lambda-Aurigae> LUFA is the usb library
[19:06:29] <Lambda-Aurigae> not the serial USART library.
[19:07:00] <goddard> I use Serial_SendByte() and that is a LUFA function right?
[19:07:01] <Lambda-Aurigae> with LUFA you wouldn't need a usb-serial adapter..you could just make it a CDC device.
[19:07:11] <Lambda-Aurigae> no clue.
[19:07:24] <goddard> yeah Lambda-Aurigae but this is like a pass through device for two hosts
[19:07:36] <goddard> really cheap
[19:08:25] <goddard> let me show you
[19:08:32] <goddard> http://gimx.fr/wiki/index.php?title=DIY_USB_adapter
[19:08:49] <goddard> im not using the software piece of this project
[19:09:04] <goddard> i am using some of the project code for the DIY USB adapter though
[19:09:15] <goddard> i can show you that
[19:09:38] <Lambda-Aurigae> so, you are trying to make a usb - serial - serial - usb device?
[19:09:51] <goddard> https://github.com/matlo/GIMX-firmwares/tree/master/EMUXONE
[19:10:08] <goddard> Lambda-Aurigae: yeah for a cheap USB sniffer
[19:10:08] <Lambda-Aurigae> why not just get a pair of usb-serial adapters and plug them together through a null modem and be done with it?
[19:10:32] <goddard> Lambda-Aurigae: I think to manage special cases
[19:10:38] <goddard> some device have security chips
[19:10:47] <Lambda-Aurigae> ok.
[19:10:54] <goddard> the teensy faces that side to handle those
[19:10:56] <Lambda-Aurigae> I'm not reading through the code to figure out what's wrong.
[19:11:09] <goddard> Lambda-Aurigae: its only really 1 file
[19:11:12] <goddard> but ok no problem
[19:11:15] <goddard> thanks for your tips
[19:11:26] <Lambda-Aurigae> check your hardware...then check your hardware again.
[19:11:41] <goddard> Lambda-Aurigae: yeah i didn't realize that about these devices
[19:11:53] <Lambda-Aurigae> send a constant stream of 0b10101010 or 0b01010101 and see what happens
[19:12:15] <goddard> ok
[19:12:33] <goddard> ill make sure it isn't my software either
[19:12:37] <Lambda-Aurigae> get a logic sniffer or oscilloscope and watch the actual transmitted data and see what is being transmitted vs what you are receiving.
[19:12:43] <goddard> using async serial model
[19:12:58] <goddard> isn't an oscilloscope super expensive?
[19:13:07] <Lambda-Aurigae> cheap ones are under 200 dollars.
[19:13:12] <goddard> I have an openvizsla
[19:13:22] <goddard> open source hardware and software sniffer
[19:13:23] <Lambda-Aurigae> cheap logic analyzers can be had for under 50 dollars.
[19:13:30] <goddard> but the guy that made it passed away
[19:13:37] <goddard> so the software kind of isn't great
[19:13:48] <Lambda-Aurigae> and, I'm off to break things.
[19:13:50] <goddard> oh yeah? ill have to look
[19:13:55] <goddard> later