Back
[00:05:35] <MarkX> k cool
[00:18:32] <ashu> quit
[00:27:12] <rue_house> no, you have to type it with a slash, like this
[00:27:22] <rue_house> I was tricked
[00:28:30] <Casper> you're too easy to trick
[08:25:18] <WormFood> http://www.fischl.de/avrusbboot/bilder/avrusbboot_circuit.png What is the function of the two 68 ohm resistors, inline with the usb data lines? I'd guess it would be to limit the current, with the difference in voltages between the data lines, and the power lines. But, I still see them, with 3.3 volt powered AVRs.
[08:25:48] <WormFood> If my AVR is already 3.3 volts, would I need those 2 resistors?
[08:27:29] <cehteh> just add them, maybe they are also for the case the ports are wrongly driven on both sides
[08:27:53] <WormFood> I want to say the usb data lines are even lower than 3.3
[08:28:22] <cehteh> iirc yes, but cant remember the exact specs
[08:28:41] <WormFood> I want to say the data lines are like 1.1 volts, or something odd like that.
[08:28:49] <cehteh> but they get driven on both sides alternatively ...
[08:29:08] <cehteh> if some error happens and host and gadget drives the lines you get some magic smoke
[08:29:23] <WormFood> not out of the avr
[08:29:25] <cehteh> i tihnk the resistors there shall prevent that
[08:29:30] <WormFood> all the avr's ports are current limited.
[08:29:32] <cehteh> yes maybe your host port
[08:30:01] <cehteh> not really current limited but design limited, its not a protection feature and the avr may be damaged from that
[08:30:05] <WormFood> In fact, even atmel mentions that the AVR's port's current limiters will allow it to directly drive an LED, without any current limiting resistors.
[08:30:19] <cehteh> yes i did that and it failed
[08:30:25] <WormFood> really?
[08:30:29] <WormFood> I did that, and it worked fine.
[08:30:32] <cehteh> after some time
[08:30:38] <WormFood> Of course, I still prefer to use the current limiting resistors.
[08:30:46] <WormFood> But, I've never burned out an LED that way.
[08:30:55] <WormFood> Of course, I don't remember running it for a long time that way.
[08:31:12] <cehteh> and even if its current limited .. you dont want 40mA on data lines
[08:31:48] <cehteh> if its only for a bootloader and you want to safe components, then maybe leave the resistors out
[08:32:11] <cehteh> (or put them on the host/connector side)
[08:49:00] <jacekowski> WormFood: usb data lines are 3.3V and 5V tolerant
[08:49:16] <jacekowski> WormFood: scrap that
[08:49:27] <jacekowski> WormFood: the usb standard says usb lines are 3.3V and 5V tolerant
[08:49:38] <jacekowski> WormFood: in reality the 5V tolerant part is not always the case
[08:49:54] <inflex> lo folks
[09:00:05] <WormFood> Yeah, I found that on the wikipedia page, I just got distracted, and forgot to say anything here about it.
[09:06:39] <cehteh> jacekowski: if you implement a usb port you are responsible for making it 3v and 5v tolerant
[09:09:41] <twnqx> doesn't mean people di.
[09:09:44] <twnqx> do*
[09:12:50] <WormFood> So, armed with that information, I'd guess those 68 ohm resistors, are to make it tolerant of some system feeding it 5 volts.
[09:13:20] <WormFood> 你好 `z
[09:18:31] <cehteh> not 5v but if both sides drive the line to different potentials
[09:18:57] <cehteh> aka host sends 3.3v, gadget pulls it to gnd
[09:19:02] <cehteh> or vice versa
[09:19:22] <cehteh> that shouldnt happen, but better safe than sorry
[09:32:30] <ne0phyte> argh. I'm trying to program an ATtiny20 using an olimex avr-isp-mk2 and avrdude but I keep getting a wrong device ID (starting with 0x50). I checked the wiring a couple times and tpi data, tpi clk, reset, vcc and gnd seem to be correct :|
[09:32:55] <ne0phyte> any hint? I compiled and tried using the latest avrdude too
[09:33:37] <Casper> do you have a tiny20 or tiny20p?
[09:33:51] <Casper> the picopower series don't have the same ID
[09:33:59] <ne0phyte> I have an ATtiny20-XUR to be exact
[09:34:08] <ne0phyte> so I guess no p
[09:34:50] <ne0phyte> the id keeps changing so it's not just a different device ID, but I'm not sure why
[09:35:02] <Casper> oh keep changing... breadboard?
[09:35:04] <ne0phyte> I flashed tons of other atmels using ISP before
[09:35:24] <ne0phyte> no breadboard, it's a TSSOP-14 package :D but I have a couple more PCBs and controllers
[09:35:32] <ne0phyte> gonna try that next
[09:35:37] <Casper> it can be a few things
[09:35:44] <Casper> try to slow down the programming speed
[09:35:51] <Casper> and ensure that it have very stable power
[09:36:48] <ne0phyte> right now it's powered by the programmer. maybe I should check if the programmer is working at all
[09:36:56] <ne0phyte> I bought so I could program TPI devices
[09:38:23] <ne0phyte> mh. programmer seems to be working. was able to check the fuses of an atmega32u4 via ISP
[09:39:58] <cehteh> ne0phyte: tried -B to slow it down?
[09:40:29] <WormFood> I have to use the -B option with my ATmega88
[09:40:46] <cehteh> it often helps when something is unstable
[09:40:50] <ne0phyte> cehteh: yeah, exactly the same here
[09:40:54] <cehteh> ah and change the usb cable ..
[09:41:13] <cehteh> made me a lot WTF ..with a bad usb cable and similar problems
[09:42:08] <cehteh> didnt know that usb can have a "partially, but not just enough" working state
[09:42:26] <cehteh> moar -B then
[09:42:39] <ne0phyte> oh lol I just realized I don't have a pull up on reset
[09:43:08] <cehteh> reset has a weak internal pullup
[09:43:11] <ne0phyte> but still doesn't seem to work.. maybe I killed it while soldering it (but I highly doubt that)
[09:43:18] <cehteh> normally that suffice for such tasks
[09:43:28] <cehteh> moar -B
[09:43:31] <cehteh> -B 32
[09:43:43] <ne0phyte> gonna see if I can find another cable
[09:43:48] <ne0phyte> the stupid programmer needs usb b
[09:45:23] <ne0phyte> -B doesn't seem to help. I always get 0x50____ IDs
[09:46:00] <WormFood> I wonder if a 24.576 Mhz xtal, divided by 2, would be close enough to 12 Mhz, to make the usb emulation work.
[09:47:13] <ne0phyte> brb, gonna assemble another PCB and see if that "helps"
[09:50:54] <ne0phyte> lol
[09:51:04] <ne0phyte> thanks for the help haha
[09:51:17] <ne0phyte> literally just the controller on a PCB with pin headers and now it's working
[09:51:34] <ne0phyte> it's exactly the same as the other one minus a two resistors and a couple of WS2812b LEDs
[09:54:12] <cehteh> WormFood: doubt that, but maybe the v-usb source can be tweaked with some strategic NOP's
[09:56:52] <cehteh> anyway .. out for a bike ride .. bbl
[10:18:19] <WormFood> woot! Found a 12 Mhz crystal. Only down side, is it's still in a functional device, that I sometimes use (was just using it a few days ago)
[10:19:36] <Casper> order new xtal, then canibalise it
[10:21:12] <WormFood> You mean replace it on this equipment?
[10:21:15] <WormFood> not worth my time.
[10:21:36] <WormFood> I found a 20 mhz, xtal, on a device that is broken...well, it's fixable, but not worth it to me.
[10:22:28] <WormFood> USB to hard drive interfaces are so cheap, it's not worth my time to fix them. IF they work, then fine, but I'm not gonna put the time or effort into fixing something I can replace for $10, with something even better.
[10:26:34] <Casper> yeah
[10:26:54] <Casper> I need to order one.. or not... might just put a relay in my nas instead
[10:27:37] <Casper> but I don't like to put a relay on the psu of the computer...
[10:28:40] <Casper> sure thing, I,m gotta put a good flywheel diode AND a snubber, and maybe a CLC filter.... and hope it will never send back emf down the rail
[10:33:38] <`z> WormFood: o/
[10:34:09] <WormFood> I see you're in #mandarin too ;)
[10:34:32] <WormFood> 你住在什么市?
[12:17:45] <lorenzo> Thank you for your interest in Atmel products, unfortunately we are unable to
[12:17:45] <lorenzo> approve your sample request order 900427 at this time.
[12:17:46] <lorenzo> boooo
[12:44:39] <dsal> I was looking at some of the asm code from a simple C program and don't quite understand all the junk at the beginning. Tons of rjmp that appears to make sure it starts from 0, then zeros out the status register and sph and spl before calling main. What's the reason for all the rjmps?
[12:45:12] <dsal> e.g.:
https://www.irccloud.com/pastebin/gP47Rb2w/avr%20asm
[12:49:32] <dsal> Oooh. Those are the interrupt vectors, aren't they?
[13:11:31] <Lambda_Aurigae> lorenzo, you didn't lie convincingly enough.
[13:11:59] <Lambda_Aurigae> dsal, yes...that's your interrupt table.
[13:12:08] <lorenzo> Lambda-Aurigae: eh, I did my best. some corporate bullshit in the field, Mouser as partner
[13:12:13] <lorenzo> shipped to office address and work email
[13:12:18] <lorenzo> but nada :(
[13:12:25] <dsal> Lambda_Aurigae: Thanks. I keep dropping questions in and then figuring them out. I should make my own channel as not to distract people.
[13:12:57] <lorenzo> Lambda-Aurigae: I'm starting to think they don't sample modules / boards. simple AVR chips go through just fine
[13:13:05] <Lambda_Aurigae> dsal, I would say 90% of the questions asked in here about avr chips or gcc could be answered by reading the manual...and are...just not by the person asking the question.
[13:13:32] <Lambda_Aurigae> lorenzo..yeah. only ever got one board sampled.
[13:13:41] <lorenzo> trying to get ATWINC1500
[13:13:42] <Lambda_Aurigae> ok....xchat is going stupid...brb.
[13:17:11] <dsal> Lambda-Aurigae: Yeah. There's certainly a lot to read. I'm just a couple days into actually trying to learn some avr. Moved an RC radio project from some arduino junk to plain avr-gcc in the last couple of days. I hadn't played with interrupts or low level port stuff or anything before that. I kind of like it.
[13:18:47] <Lambda_Aurigae> I recommend reading the datasheet for your avr and the avr-gcc website at a minimum before going any farther...but that's just me and I'm an ass.
[13:18:56] <Lambda_Aurigae> err..
[13:18:59] <Lambda_Aurigae> not avr-gcc...avr-libc
[13:19:20] <Lambda_Aurigae> http://www.nongnu.org/avr-libc/
[13:19:31] <dsal> Heh. Yeah. I've been reading bits of each. I'm working on two different chips which is also a bit helpful.
[13:19:48] <Lambda_Aurigae> when I ordered my first avr I read the manual while it was shipping.
[13:19:57] <Lambda_Aurigae> manual/datasheet
[13:20:18] <Lambda_Aurigae> but, I read 200 pages a day....about half and half of techy stuff like datasheets and scifi/fantasy.
[13:20:20] <dsal> That would've been nice. I've got piles of junk all over the place. I just try to brute force my way through it. Then later, try to understand what I've done.
[13:23:26] <cehteh> re
[13:23:28] <dsal> I'm doing reasonably well just trying things and scoping it. Noticing something's 2x too big. Realizing I gave it the wrong F_CPU, etc...
[13:24:25] <cehteh> dsal: i am working on a small OS for avrs and added a driver for CPPM signals recently
[13:26:22] <dsal> Neat. I've played with chibi on a little stm32f0 thing I made. I'd kind of like to try that on AVR as well. I'm a few levels away from where you are. :)
[13:27:06] <cehteh> much simpler than chibios
[13:27:48] <cehteh> and just started around chrismas .. in spare time
[13:29:34] <Lambda_Aurigae> and I'm working on a C interpreter based OS for avr and pic32.
[13:29:53] <Lambda_Aurigae> will require a rather large avr though...just barely fitting on an atmega1284p so far.
[13:30:29] <cehteh> haha and thats yet without any user applications loaded?
[13:30:51] <Lambda_Aurigae> yeah..user apps will be in sram, either internal or external.
[13:31:01] <cehteh> paging on avrs
[13:31:04] <Lambda_Aurigae> looking to use external 1Mbit serial sram for it.
[13:31:10] <Lambda_Aurigae> interpreted C
[13:31:16] <Lambda_Aurigae> so it's gonna be slow anyhow.
[13:31:18] <cehteh> i know picoc
[13:31:44] <cehteh> i never used it, only read the docs and my quacdopter supports it
[13:31:57] <cehteh> but i dont really understand why they picked C for interpreting
[13:32:31] <cehteh> some other languages are better suited for that (think about forth)
[13:36:50] <Lambda_Aurigae> I don't know forth.
[13:36:51] <Lambda_Aurigae> I know C
[13:37:01] <Lambda_Aurigae> hence, using picoC as a basis actually.
[13:37:10] <Lambda_Aurigae> I could do BASIC but I wanted something different.
[13:38:20] <dsal> cehteh: My understanding of picoc is that there's not much smaller out there.
[13:38:23] <dsal> Well, forth I guess
[13:38:50] <Lambda_Aurigae> I've gotten it somewhat smaller with some code optimizations(read "ripped the guts out of it"(
[13:38:53] <Lambda_Aurigae> )
[13:39:35] <cehteh> how safe is picoc? can one cause some out of bounds access and crash the system?
[13:39:49] <Lambda_Aurigae> it's so so
[13:40:01] <Lambda_Aurigae> I've been rewriting it majorly to fix things like that too and to shrink it down.
[13:40:39] <Lambda_Aurigae> by the time I get done I probably might as well have written it from scratch I bet.
[13:40:55] <Lambda_Aurigae> anyhoo...gotta run...customers screaming that they want their copiers fixed and/or installed.
[13:44:37] <dsal> cehteh: What's your OS do?
[13:45:05] <dsal> I'm super new here, but naming all the things consistently seems like a pretty big win.
[13:45:53] <cehteh> scheduling functions by timer and work queues
[13:46:03] <cehteh> and adding drivers for things on demand
[13:46:26] <cehteh> currently there is some serial stuff and that cppm parser
[13:46:27] <dsal> e.g. TIMSK vs. TIMSK0 and WDTCR vs. WDTCSR (having to alias that kind of junk in a .h)
[13:46:42] <cehteh> thats is rather hidden from the user
[13:46:57] <cehteh> you just say "call function X at time T"
[13:47:08] <dsal> Sure, yeah. That makes sense.
[13:47:30] <cehteh> function X can say 'call myself again in xxx ms
[13:47:33] <cehteh> and so on
[13:47:50] <dsal> I'm reading frsky D8 packets off a cc2500. I set my timer down to 0 whenever I read a packet to keep time ~in sync. Watchdog for failsafe.
[13:48:17] <cehteh> currently i am working on documentation and infrstructure and soon the first project with it, thats some light/led controller for RC models
[13:48:37] <cehteh> frsky here too
[13:49:41] <dsal> Oh cool. I made some little boards for that sort of thing. I've done a bunch of different programs for them. Can't figure out what people want other than "lights!" Someone mentioned distinguishing colors, so I made a little pwm -> color wheel thing.
[13:49:56] <cehteh> lol
[13:50:14] <dsal> But I've also sniffed MSP between a flight controller and an OSD so I could have fancy light effects based on stick inputs and stuff without using any extra IO pins on the FC.
[13:50:20] <cehteh> well ling time goal is to port it to STM32 and make my own copter firmware
[13:51:08] <dsal> I've been having a little trouble getting into chibios. I've blinked lights with it, but it wasn't as... fun as avr.
[13:52:06] <cehteh> yeah i just want to make something simpler
[13:52:27] <cehteh> in minimum configuration less than 1k flash and few bytes ram are enough
[13:52:49] <cehteh> and no processes/threads ... only one stack by concept
[13:53:06] <cehteh> i am using ATtinys a lot
[13:53:26] <cehteh> https://pbs.twimg.com/media/CeU4GP_WIAAWRsV.jpg:large
[13:53:45] <cehteh> and i dont waste the holes on breadboards
[13:53:52] <dsal> heh
[13:54:04] <dsal> That was me last night...
https://usercontent.irccloud-cdn.com/file/Aap8eOHw/why%20r
[13:54:43] <cehteh> so much unused holes!
[13:54:43] <dsal> Such a mess, almost entirely probes.
[13:54:54] <cehteh> on my board too
[13:55:10] <cehteh> everything which leaves on the left are probes
[13:55:18] <cehteh> in the back you see a D8R
[13:56:10] <dsal> That little thing by my yellow scope probe is a cc2500. This is an attiny85 making it talk D8 and then spitting out SUMD.
[13:56:36] <dsal> It's not super great at the serial parts or timing, but it's probably good enough. A crystal would make a huge difference.
[13:58:28] <cehteh> i have some code to sync the RC oscillator with some external signal
[13:58:48] <cehteh> using attiny84 here and syncing it with the d8r's 27ms frame
[13:59:23] <dsal> 27ms? ppm?
[13:59:25] <dsal> Oh, you said that.
[13:59:27] <cehteh> yes
[13:59:40] <cehteh> 27ms firmware ppm
[14:00:10] <dsal> D8 is ~9ms. I haven't quite figured out how to get the pin change interrupt thing doing the right thing, though, so I'm still polling the radio like a farmer.
[14:01:32] <cehteh> i use the input capture
[14:01:41] <dsal> Also, you get three packets and then an empty slot over which you can transmit, but you still have to change channels every 9ms. I have to use that timer anyway, but I was hoping I could go to sleep while waiting for timer or pin. Probably still useful.
[14:01:55] <cehteh> alternatively i'll add pinchange later in case input capture is needed for something else
[14:02:08] <cehteh> but there are some tricky things
[14:02:12] <dsal> I only have a vague concept of input capture.
[14:02:19] <cehteh> its all interrupt base here and works very well now
[14:02:33] <cehteh> its basically like the lap-button on a stopwatch
[14:02:44] <dsal> But this is a lower level thing. SPI to a cc2500 and actually implementing the radio itself. i.e. I'd be D8R on your picture. :) (except SUMD out instead of cppm)
[14:03:12] <cehteh> thats a SDR chip?
[14:03:23] <dsal> No, it's the radio chip frsky uses.
[14:03:29] <dsal> http://www.ti.com/lit/ds/symlink/cc2500.pdf
[14:03:33] <cehteh> ah
[14:03:57] <cehteh> well frsky receivers have a stm32 on board
[14:04:04] <cehteh> i guess mostly ideling
[14:04:53] <dsal> Yeah. Having the higher clock speed is pretty handy for creating reliable ppm signals. I picked up a frsky clone built on a m328p and it's... not awesome. Channels drifting about 7µS just from timing inaccuracies. No reason to use cppm anyway.
[14:05:23] <dsal> Well, except the hardware config on this thing is incredibly stupid. It's using bit banged SPI and doesn't even have the UART connected.
[14:05:41] <cehteh> you know that tiny85 has this PLL and you can run timer1 at 64mhz?
[14:06:56] <dsal> I don't know much about it. :) Just what someone explained to me about the accuracy of the internal clock vs. crystals and how higher clock speeds make it easier to more accurately do the things.
[14:07:16] <dsal> I don't really care that much since I'd rather have SUMD in general.
[14:07:18] <cehteh> the internal clock has some jitter and drifts like shit
[14:07:39] <cehteh> there is nothing much you can do about the jitter, but drift can be compensated/calibrated
[14:09:13] <dsal> Hmmm... I'm resetting my timer on packet request. One tick difference kind of sucks for me, though. It should be possible to do something sensible as long as I'm getting packets. But I'll probably just stick a crystal on a board.
[14:09:22] <cehteh> 7µs drift .. i call that bugs :D
[14:09:45] <cehteh> hah .. i told that yesterday, never ever touch a running timer :d
[14:09:57] <cehteh> mmkay .. in some cases
[14:09:59] <cehteh> but i dont
[14:10:04] <cehteh> just let the timer run
[14:10:13] <dsal> Could very well be bugs, but it's jittery:
https://usercontent.irccloud-cdn.com/file/LBl7yDUl/offsets
[14:10:27] <dsal> Setting it back down to 0 isn't good?
[14:10:34] <cehteh> depends
[14:10:47] <cehteh> i try to avoid it as much as possible
[14:10:55] <cehteh> how reliably can you set it to 0?
[14:11:12] <cehteh> i mean even when you do that in a interrupt, this interrupt might be delayed by some other one
[14:11:55] <cehteh> mµOS so far needs only one timer for everything and that one is just spinning freely once started
[14:12:26] <cehteh> can be a 8 bit timer as well, but for high resolution with /1 prescaler 16bit timer is recommended
[14:13:10] <cehteh> well it prolly doesnt do the most efficient time handing, it aims to be correct and universal there
[14:13:48] <cehteh> and i do a little bit filtering on the cppm signals
[14:15:21] <cehteh> there is a raw mode which stores the time of the signal lengts in uint16_t and a cooked mode which has some better filtering and stores a int8_t -125 to 125
[15:02:45] <dsal> cehteh: Well, in my case, it's only really an issue for timing out the requests, so I'm OK if it's just a little delayed. I suppose I could run the timer a little slower all the time, but resetting it helps with drift as well.
[15:59:03] <phinxy> Ruined two 128's today, short story: First i tought i soldered the MCU the wrong way and i had to toss it. Then it was the right way all along.. toss another.
[16:03:34] <phinxy> I bet if i just had some energy left i could make the project work with a controller from the tiny family
[16:04:43] <phinxy> i need 6 inputs, hardware I2C, 1 output
[16:04:59] <phinxy> 16mhz
[16:06:14] <phinxy> Is there a webpage where you can feed in chip requirements like this and get a suitable chip?
[16:07:48] <lorenzo> phinxy:
http://www.atmel.com/products/selector_overview.aspx
[16:08:01] <lorenzo> phinxy: no AVR in the tiny family has hardware i2c though
[16:08:21] <lorenzo> they have the USI thing
[16:14:16] <Lambda_Aurigae> phinxy, atmel.com
[16:28:16] <phinxy> if my .hex is 66KB does that mean flash needs to be >66 Kbytes?
[16:28:31] <Lambda_Aurigae> no.
[16:28:41] <vaskozl> Hey I just downloaded this really old (2007) bldc example code from the avr website:
https://skozl.com/s/sensor_three_phase_BLDC.c
[16:28:45] <Lambda_Aurigae> hex is a text representation of the data to be stored on the chip.
[16:28:48] <vaskozl> It include inavr.h and ioavr.h
[16:28:55] <Lambda_Aurigae> check out the hex file format...google is your friend.
[16:28:58] <vaskozl> Are those still a thing?
[16:29:22] <phinxy> that .hex contains all .data things that go everywhere including flash part?
[16:29:25] <vaskozl> Or are they something only available in avr-studio
[16:30:28] <Lambda_Aurigae> vaskozl, no clue.
[16:30:50] <Lambda_Aurigae> phinxy, yes....each line contains an address in flash and data to write it.
[16:30:59] <Lambda_Aurigae> it is considerably larger than what actually gets written.
[16:31:04] <Lambda_Aurigae> like, 3 times the size or so.
[16:31:27] <phinxy> i used hex2bin and the output bin is 24KB. solved!
[16:32:46] <phinxy> i guess the map file could help
[16:39:54] <dsal> phinxy: avr-size --format=avr --mcu=yourcpuhere yourfile.elf
[18:58:46] <vaskozl> Hey is there a difference between cbr and andi
[18:58:50] <vaskozl> and sbr and ori ?
[18:59:04] <vaskozl> I'm sure they are different but I just fail to see.
[19:01:16] <vaskozl> Um, maybe they are the same?
[19:01:50] <vaskozl> Yeah they have the same opcode..
[20:41:52] <inflex> Anyone done Attiny5/10 programing using a usbtiny programmer with the avrdude TPI patch?
[20:42:40] <Lambda_Aurigae> usbtiny can do tpi?
[20:43:14] <inflex> with a patch in avrdude
[20:43:21] <inflex> https://savannah.nongnu.org/patch/?8924
[20:43:50] <inflex> trouble is, I can't find a writeup for it on "how to"
[20:44:01] <inflex> (ie, what the pinouts are, various examples etc)
[20:44:14] <Lambda_Aurigae> it seems to work with the sparkfun programmer that uses the usbtiny interface.
[20:44:21] <Lambda_Aurigae> not necessarily the usbtiny from adafruit.
[20:44:58] <Lambda_Aurigae> I'm not familiar enough with tpi to know though.
[20:45:28] <Lambda_Aurigae> only have one attiny10 and I use my programmer from tom_itx to program it.
[20:46:00] <inflex> ja, I have a pair of the tom programmers
[20:46:13] <inflex> trouble is, I must have done something with them and they don't work properly now (to be fair, they're old now)
