Back
[03:12:10] <antto> Evidlo turns the integer from linear to x*x shaped
[03:13:18] <antto> some precision is lost with that tho
[03:14:04] <antto> "some" == half
[05:22:32] <pepijndevos> My compiler says Data: 117 bytes (91.4% Full), how far can I go without getting into trouble?
[05:25:33] <Arch-TK> er what?
[05:26:34] <pepijndevos> This is the data that is loaded into ram, right? So I assume C uses some stack space too. So if I fill all the RAM, I'm probably going to get in trouble.
[05:30:03] <Xark> pepijndevos: Chip with 128 bytes of RAM? Getting pretty tight. Avoid nested subroutines and local variables. :)
[05:30:47] <Arch-TK> pepijndevos: this sounds implementation defined.
[05:30:51] <Xark> pepijndevos: It is not easily deterministic (depends on your codes behavior etc.)
[05:30:59] <Arch-TK> pepijndevos: are you writing for a microcontroller?
[05:31:12] <pepijndevos> Yea... about how much stack space does a function call consume?
[05:31:16] <pepijndevos> Attiny25
[05:31:19] <Arch-TK> implementation defined
[05:31:23] <Arch-TK> ask your implementation.
[05:31:37] <pepijndevos> avr-gcc
[05:31:54] <Xark> pepijndevos: At least 2 bytes, but C usually saves a few other registers, so often 4 or 6.
[05:32:07] <Arch-TK> some people in #avr might know
[05:32:15] <Arch-TK> Xark: C doesn't do any of that, the implementation does.
[05:32:20] <Xark> It depends on your code.
[05:32:21] <Arch-TK> please don't mix these two ideas
[05:32:35] <Xark> Fine, avr-gcc...
[05:33:13] <Xark> Arch-TK: This is #avr, so avr-gcc is (nearly) assumed. :)
[05:33:23] <Xark> (for C/C++ code at least)
[05:33:45] <Arch-TK> I thought I was in ##c
[05:33:49] <Arch-TK> *facepalm*
[05:34:03] <Arch-TK> in any case
[05:34:25] <Arch-TK> the attiny25 has 32 general purpose 8 bit registers
[05:34:49] <pepijndevos> I'll try to save some RAM and flatten some code.
[05:35:05] <Arch-TK> it has 2K bytes of programmable memory
[05:35:11] <Arch-TK> and 128 bytes of ram
[05:35:23] <Arch-TK> I doubt function calls will save all 32 registers
[05:35:58] <Xark> Arch-TK: No, as I mentioned, it depends on your code. Worst case, it will save like ~10 IIRC.
[05:36:15] <Xark> (but that is a "busy" function with lots of locals)
[05:36:33] <Arch-TK> You would need to consult the ABI that avr-gcc implements:
http://gcc.gnu.org/wiki/avr-gcc
[05:36:37] <Xark> Then there are others that are caller saved...
[05:37:19] <Xark> If you want details, but flattening code and squeezing almost always helps (and the compiler gives the helpful feedback). :)
[05:38:25] <pepijndevos> thanks
[05:42:49] <Xark> pepijndevos: Do note the compiler message is mostly about static or global variables (or strings etc. that aren't explicitly in PROGMEM).
[05:43:24] <Xark> The compiler can't know stack usage at run-time (but not too hard to add a check if needed for testing).
[05:43:57] <pepijndevos> Right. Well, kinda hard to relay the info back to me at runtime from a tiny with all its pins occupied.
[05:44:31] <Xark> Well, yes... :)
[05:44:54] <Xark> pepijndevos: I tend to disassemble the code to check on avr-gcc.
[05:45:26] <Xark> avr-objdump -d *.elf
[05:46:03] <pepijndevos> I'm not a fluent speaker of AVR assembly, but it'll be fun to look at.
[05:46:49] <Xark> pepijndevos: You can at least see if there is "a lot" of register push at the start of functions etc. pretty easily.
[05:47:11] <Xark> (to estimate stack usage - or at least spot the worst offending functions)
[05:49:08] <pepijndevos> Oh, here is some pushing going on, 4 of them.
[05:53:27] <pepijndevos> So does that mean calling that function consumes 4 bytes of stack space?
[05:54:28] <Xark> Generally one byte per register. Also it will "subtract" from the stack pointer for local space (IIRC).
[05:55:03] <Xark> Hopefully you don't have any functions overflowing the registers. :)
[05:55:16] <Xark> (or like arrays on the stack etc.)
[05:55:24] <pepijndevos> What is "overflowing" registers?
[05:55:42] <Xark> Also called "spilling".
[05:56:11] <pepijndevos> I only use a hand full of local variables, all uint8.
[05:56:22] <Xark> As mentioned there are 32 registers, of those some are used for system things, but most are available for locals. If you use too many or have large objects then they will have to use the stack.
[05:56:54] <pepijndevos> I see
[05:56:58] <Xark> Cool. This is why I say "hopefully" you aren't spilling (not common AVR unless "complex" calculations).
[05:58:04] <Xark> ^on
[06:01:58] <pepijndevos> Data: 96 bytes (75.0% Full), should do the trick then.
[06:14:56] <Xark> Nice. :)
[06:33:55] <twnqx> Lambda-Aurigae: use tables instead of bitshifting!
[06:34:13] <twnqx> LUTs make everything faster!
[06:34:49] <twnqx> on the topic of speed... did any of you ever implement RSA or similar public key crypto in an AVR to see how slow it is?
[06:35:11] <twnqx> i seem to remember i wrote some RSA ASM on my 386 and it was too slow to be useful :X
[06:50:22] <Valen> AVR's might be faster than your 386 ;-P
[06:51:06] <Valen> Though I imagine the 386 DX might well make a big difference there
[06:52:26] <twnqx> it was a dx40...
[06:52:39] <twnqx> but i might have been a dumb kid back when i did it :P
[06:52:46] <Valen> well laaaade dah Mr yuppy fancy pants
[06:52:53] <Valen> bet it even had a working turbo button
[06:53:01] <twnqx> lol
[06:53:02] <twnqx> of course!
[06:53:17] <twnqx> it was my first PC and i was like... 16 or so
[06:54:04] <Valen> I really should write a PKI implementation
[06:54:10] <Valen> just so I understand it
[06:54:26] <Valen> all the certificate signing and passing around stuff gets so complex
[06:54:42] <twnqx> i just read the wikipedia article on digital signatures
[06:54:53] <twnqx> in the end it's pretty simple
[06:55:17] <twnqx> hash content with a function of your choice (sha-256 or so recommended)
[06:55:55] <twnqx> encrypt result with your private key of an asymmetric cipher of your choice (elliptic curves with non-NIST curves recommended)
[06:56:10] <twnqx> the result is your "signature"
[06:57:13] <twnqx> in case of certificates, those contain all the info (public key, algorithms used, identity information) on top
[07:01:08] <Valen> heh, sounds simple
[07:01:12] <Valen> gets complex ;->
[07:01:37] <twnqx> true
[07:02:18] <twnqx> lots of hashing functions (md5, sha1, sha2 aka 256, sha3, rc4), some of which are considered unsafe
[07:02:33] <twnqx> lots of ciphers (rsa, dsa, elliptic curves with varying curves)
[07:02:49] <twnqx> asn.1 notation in classic certificates, but a dozen ways to store them on disk
[07:03:20] <twnqx> decisions like including parent certificates or not
[07:27:25] <phinxy> Whats a good cutoff frequency for a inductive low pass filter to power a Atmega MCu 16mhz ?
[07:28:19] <phinxy> 300khz? because i have some I2C at 400khz and i dont want that to spread anywhere
[07:29:35] <jacekowski> twnqx: there is AES crypto example from atmel somewhere
[07:30:56] <NicoHood> We got a 3kb bootloader with a 4kb (max) bootloader section.
[07:30:56] <NicoHood> The bootloader should use a 2kb AES library that is placed inside the application section.
[07:30:56] <NicoHood> The AES library should be callable with jump tables right below the bootloader start (0x7000).
[07:30:56] <NicoHood> Below the jump table should the aes functions placed. This way you could update them later.
[07:30:56] <NicoHood> How can I instruct the makefile to place it inside the 4kb section, but the AES functions somewhere else?
[07:34:52] <jacekowski> http://www.atmel.com/images/doc2589.pdf
[07:35:16] <NicoHood> this does not answer my question
[07:35:51] <NicoHood> this bootloader encrypts. i just use it for signing and doing totally different stuff. I just need to place some functions "somehwere else"
[07:50:10] <twnqx> jacekowski: i am looking explicitly for asymmetric ciphers to authenticate hardware
[07:50:44] <twnqx> symmetric ciphers are pointless for me, as the verifying side won't be protected
[07:50:49] <twnqx> or rather, can't be
[07:51:50] <twnqx> and my personal choice would by elliptic curves as they feature shorter keys, unlike RSA where you need 4kbit keys
[07:54:15] <liwakura> twnqx: has it to be secure against MITM attacks?
[07:54:23] <twnqx> yes
[07:54:32] <twnqx> well, not really
[07:54:49] <liwakura> look into an challenge-auth method like apop
[07:54:53] <twnqx> but the idea is to be secure for unmodified verifiers. nothing helps you if that's not the case
[07:55:20] <liwakura> hm.
[07:55:21] <twnqx> sure, challenge-auth with asymmetric ciphers is the basic idea
[07:55:37] <liwakura> asymmetric stuff is going to be rough on an AVR
[07:55:48] <twnqx> basically, have a signed public key in a data block
[07:55:51] <liwakura> its even slow on normal PC's
[07:56:12] <twnqx> send a challenge, have the authentication device encrypt it, verify the result
[07:56:48] <twnqx> so you are safe against cloning the data block (which could be read from the wire) as the copier wouldn't have the private key
[07:57:09] <twnqx> ans you are safe against cloning the signed block as you have a private key for the signing somewhere outside the device
[07:57:28] <twnqx> but it relies on asymmetric ciphers :P
[07:57:55] <twnqx> so i am wondering whther i can do it with a small avr, or just throw an actel igloo nano at it
[07:59:39] <twnqx> single RSA encryption/verification was fine on my 486 dx2 66 iirc
[07:59:51] <twnqx> just didn't work out on the 386 dx40, for whatever reason
[11:23:41] <WormFood> Regarding RSA on the AVR... I have some code somewhere, in ASM, that does RSA on the ATmega128. It was part of a smart card emulator, for "pirate" satellite TV. I have the source code somewhere on my hard drive. I'll dig it up, if anyone is interested in it. (it emulates a 68C05)
[11:25:12] <WormFood> In time critical parts of the code, it would intercept the ROM/EEPROM address, in the emulated 68C05, and do some things in native AVR asm, for speed, then return to the emulated code.
[11:30:36] <learath> ... that seems crazy.
[11:31:14] <LoRez> dear god that must be slow.
[11:33:44] <rue_bed> a 1Mhz apple IIe could do quite a few trig equations in a second
[11:34:33] <rue_bed> 1.023Mhz, hmm those were the days
[11:35:06] <learath> Old school: Use the lowest level language in which you can solve the problem conveniently
[11:35:16] <learath> New school: Use the highest level language in which the latest supercomputer can solve the problem without the user falling asleep waiting
[11:54:00] <Jartza> assembly is convenient on avr
[11:54:45] <Lambda_Aurigae> the days of lookup tables for trig functions...
[12:38:45] <WormFood> learath, it may seem crazy, but it actually worked quite well
[12:39:34] <WormFood> LoRez, of course it was slow, but it worked, and that is what matters. It was fast enough to decode a satellite key stream. Which was designed for low power (slow) devices.
[12:39:48] <learath> WormFood: the two are not mutually exclusive
[12:39:56] <WormFood> of course
[12:40:29] <WormFood> we were using a 16 Mhz AVR. The stock card ran at 58C05 at 4.5 (or 4.0) Mhz
[12:40:43] <WormFood> er, 68C05
[12:41:11] <learath> I'm surprised 4:1 was enough.
[12:41:14] <WormFood> And, of course, the 68C05 used several cycles per instruction, so actually the AVR wasn't slow in this situation.
[12:42:49] <learath> well sure, but so does the AVR right?
[12:43:06] <WormFood> most instructions on the AVR execute in a single cycle.
[12:43:28] <learath> Interesting.
[12:43:29] <WormFood> a vast majority of AVR opcodes execute in 1 or 2 cycles.
[12:43:31] <learath> I've never looked at that.
[12:43:41] <WormFood> Yeah. It's awesome.
[12:43:57] <WormFood> it was much more than 4:1, when you consider that aspect of it.
[12:44:09] <learath> It would have to be.
[12:44:15] <WormFood> And for some of our smart card attacks, we had to count cycles.
[12:44:35] <WormFood> So, I'm very familiar with opcode cycles on the '05 (and the ST7)
[12:45:34] <lorenzo> ST7! :-)
[12:45:49] <WormFood> I had my own assembler for the ST7 that used motorola syntax.
[12:45:55] <WormFood> :D
[12:46:34] <WormFood> I took the free masm assembler, and modified the hell out of it. When I was done, it did all kinds of specific stuff, for the hardware/software I was working with.
[12:47:05] <WormFood> And, part of that, was adding support for the ST7, which is really just a 68C05 with some new opcodes, and addressing modes.
[12:48:55] <WormFood> Someone offered to give me their disassembly of that ATmega128 68c05 emulator I mentioned. I told them I wasn't interested in it, and they were surprised. I told them that I had the original source code, and gave that to them. They were impressed.
[12:49:37] <lorenzo> haha
[12:50:31] <WormFood> Someone disassembled one of my programs, and posted it publicly. They were confused about a lot of the stuff I was doing, and had a hard time documenting what it was actually doing. I gave them my heavily commented source code in return.
[12:51:56] <WormFood> And someone else, had written a program that had the same function, but it was never publicly released. When they saw my program, they thought I had just ripped off their program, and changed the name. Later, someone else gave me that program, and I disassembled it, and it was nothing like my program. He couldn't even claim I looked at his program for inspiration.
[13:06:49] <NicoHood> does Werror makes any difference in the linker command or only in the compiler command?
[13:52:17] <julius> WormFood, other peoples code always looks ugly, just saying
[15:08:39] <Jartza> the only thing preventing me of using the -Werror on avr-gcc is the stupid bug with -flto and ISR
[15:08:55] <cehteh> Jartza: i grep that out
[15:09:02] <Jartza> tagsu_isr.c:361:1: warning: '_vector_12' appears to be a misspelled signal handler [enabled by default] ISR(WDT_vect) {
[15:09:06] <Jartza> like that
[15:09:24] <cehteh> ah and no -Werror for ld
[15:10:03] <cehteh> $(CC) $(LDFLAGS) $(OBJECTS) --output $@ 2>&1 | sed 'h;:b;$b;N;N;/appears to be a misspelled signal handler/{N;d};$b;D'
[15:11:10] <cehteh> -Wl,--relax,--gc-sections -Xlinker --no-fatal-warning in LDFLAGS
[15:11:45] <cehteh> -Xlinker --no-fatal-warning disables the -Werror for the linker pass
[15:39:34] <Jartza> yea
[15:58:25] <cehteh> http://public.pipapo.org/clocksync.png .. almost 2% jitter, syncing RC osc with external clock
[16:35:01] <julius> wheres the jitter?
[16:38:41] <julius> thats a saleae logic anylyzer right?
[16:39:14] <julius> i was thinking about buying that or a oscilloscope fro 60€. how much is the logic analyzer?
[16:39:32] <Tom_itx> i like mine
[16:39:48] <Tom_itx> you can get several different models depending on your needs
[16:40:03] <cehteh> julius: 15Eur
[16:40:31] <cehteh> and memory on the computer, means i can have 2GS storage or more.. recording for hours
[16:41:23] <cehteh> upper is the input at 20ms .. second channel is the OSCCAL synced output
[16:41:29] <julius> currently i only want to check how fast my mosfet goes from on to off depending on different currents. i know that this can also be calculated....but i like to take alook
[16:42:24] <cehteh> i dont think a logic analyzer is the right tool for that
[16:42:32] <julius> no it isnt
[16:42:42] <lorenzo> julius: Picoscope was the best tool I've bought in the last years
[16:42:56] <lorenzo> https://www.picotech.com/oscilloscope/2200/picoscope-2200-portable-oscilloscopes
[16:43:19] <Tom_itx> i've used the LA way more than my scope partially just due to convenience
[16:43:32] <julius> portable? that sounds like a lot of money
[16:43:57] <Tom_itx> no the logic analyser
[16:44:08] <lorenzo> as a logic analyzer I use a random saleae clone :D
[16:44:28] <Tom_itx> i don't mind supporting the original developers
[16:44:31] <julius> does saleae got linux software?
[16:44:34] <Tom_itx> they did all the work
[16:44:35] <lorenzo> julius: yep
[16:44:38] <Jartza> I got the original too
[16:44:44] <Jartza> just because it's amazing product
[16:44:57] <julius> lorenzo, you use it with linux?
[16:45:03] <Tom_itx> i'd get one of the newer ones if i really needed it
[16:45:05] <lorenzo> julius: yup, both the picoscope and the saleae
[16:45:19] <lorenzo> works fine
[16:45:22] <julius> whats the product name on the saeleae?
[16:45:38] <lorenzo> julius: the genuine one is on their website
[16:45:46] <lorenzo> the clone one, just search for "saleae" on aliexpress
[16:46:19] <lorenzo> it's a Cypress USB IC + a buffer
[16:46:53] <Jartza> the clone has matchbox-looking crappy plastic case and the original has milled aluminum case :)
[16:47:11] <lorenzo> yeah, I also think they're using a Xilinx FPGA across all the line in the genuine ones now
[16:47:24] <lorenzo> the clone sometimes crashes at 24 MSPS
[16:47:29] <lorenzo> so you have to use it at a bit lower rate
[16:47:36] <lorenzo> but meh, does the job for me. i2c isn't that fast :p
[16:48:03] <Jartza> I've used saleae a lot for timing stuff
[16:48:23] <Jartza> I have the Saleae 16
[16:48:42] <Jartza> it's also very nice if you need to debug some parallel communication
[16:49:04] <julius> thanks guys
[16:51:21] <julius> for the oscilloscope i was thinking 20mhz, 48m samples. well those are the starter specs. i know that 20mhz isnt enough to look at "real" 20mhz but currently the fastest thing i need to look at is a 25khz pwm
[16:51:44] <jacekowski> julius: actually, 20MHz is enough to look at 20MHz
[16:51:56] <julius> the picoscope seems kinda expensive / overkill for me as a beginner
[16:52:02] <jacekowski> julius: and maybe even higher if you want to push it and can live with some distortion
[16:52:31] <cehteh> and you get a real good scope for about 400Eur ..
[16:52:34] <jacekowski> julius: thing is, picoscopes have software that is really good
[16:52:35] <julius> peak to peak voltage might not be correct
[16:52:45] <cehteh> which makes piscope even less interesting
[16:52:48] <jacekowski> julius: and it's small
[16:53:32] <cehteh> i'd like lots of hardware knobs on a scope .. not some gui on a computer
[16:53:36] <julius> true, but still... im starting out small with a 66€ usb oscilloscope
[16:53:50] <jacekowski> cehteh: since i bought a picoscope my tek is not getting much use
[16:53:54] <Jartza> I got myself Hantek dso5102p
[16:53:56] <julius> if that doesnt work i can still sell it on ebay
[16:53:58] <cehteh> yes these are cheap an crap but for that price ok
[16:54:10] <jacekowski> cehteh: when i'm away, picoscope is just a lot easier to carry
[16:54:25] <Jartza> it was about 230€ when I bought it
[16:54:29] <Jartza> I've been quite happy with it
[16:54:32] <julius> jacekowski, sure if you have to have it mobile that sounds reasonable
[16:54:36] <cehteh> yes has its uses, but consider a hobbyist with small budget who only wants one device
[16:54:51] <Jartza> it's 100MHz thingie, but actually there's a firmware hack allowing it to go to 200Mhz :)
[16:54:53] <cehteh> then something little more expensive but much more versatile makes sense
[16:54:55] <Jartza> which I've done
[16:55:08] <jacekowski> cehteh: and when i'm not away, ability to communicate with PC and save stuff and other features are really useful
[16:55:09] <Jartza> 1GSa/s
[16:55:33] <jacekowski> cehteh: and GPIB does not come anywhere close to what you can do with picoscope
[16:55:56] <cehteh> http://www.amazon.de/gp/product/B00OK3NC26 i was thinking about that one. has usb and vga and huge display on itself
[16:56:17] <cehteh> but not buying it anytime soon
[16:56:38] <jacekowski> i would like to see a modular scope
[16:57:03] <jacekowski> so one where you have knobs on separate module plugged in into ethernet or anything else really
[16:57:16] <jacekowski> and then actually ADC and signal processing in a separate box
[16:57:33] <jacekowski> outputting straight to a displayport or vga
[16:57:38] <jacekowski> not bother with local display
[16:57:43] <cehteh> agilent :D .. $$$$$$$
[16:57:48] <julius> jacekowski, what kind of work do you do?
[16:57:59] <jacekowski> julius: all sorts of stuff
[16:58:38] <julius> so whats the last thing you used a scope for?
[16:58:46] <cehteh> *now* i'd like if the tiny85 has a uart ...
[16:59:19] <jacekowski> julius: last one, acceleration/vibration measurment
[16:59:31] <Jartza> cehteh: I've heard some good praises about Owon
[16:59:31] <julius> sounds interresting
[17:00:06] <jacekowski> that was away, and all of the sudden the fact that building is vibrating when we are running a sifter became my problem
[17:00:11] <cehteh> Jartza: i compared some more, but the huge display and big memory is really the the point for the owon
[17:01:07] <jacekowski> but main issue for me is lack of space, even at home
[17:01:27] <cehteh> get a fluke scopemeter :D
[17:01:49] <jacekowski> i came really close to buying one
[17:01:55] <jacekowski> few years ago
[17:02:09] <Jartza> http://www.ebay.de/itm/151274188799
[17:02:11] <Jartza> I got that
[17:02:12] <cehteh> looking nice .. but the price.. noway
[17:02:16] <Jartza> strangely, the price has gone up a bit
[17:02:50] <cehteh> i can borrow a scope from a friend if i need one
[17:03:03] <cehteh> no urge to have one on my own yet
[17:03:16] <cehteh> would be a nice tool still
[17:03:17] <julius> fluke takes your money and your soul
[17:04:10] <cehteh> https://www.picotech.com/oscilloscope/9300/picoscope-9300-sampling-oscilloscopes
[17:04:17] <cehteh> want bandwidh?
[17:05:48] <Jartza> that's lame
[17:06:28] <Jartza> at customer I can use their lecroys :)
[17:06:36] <jacekowski> julius: and before that i've used a scope to measure resistance, it was changing too fast for a meter to measure
[17:06:52] <julius> never thought of that
[17:07:04] <Jartza> iirc, the fastest has 80GSa/s sample rate
[17:08:11] <Jartza> and something like 30GHz bandwidth
[17:09:10] <Jartza> there was even matlab integrated to the device, so you can directly calculate stuff'n'shit while measuring
[17:09:22] <jacekowski> yes
[17:09:25] <jacekowski> and c# bindings
[17:09:38] <julius> 30ghz? wow
[17:09:43] <julius> what do you do with that?
[17:09:47] <jacekowski> julius: RF shit
[17:09:52] <jacekowski> rf voodoo
[17:09:55] <Jartza> some RF stuff I understand nothing about
[17:10:34] <Jartza> the customer has nice RF-lab and all the anechoic chambers and whatnot
[17:10:49] <jacekowski> as some people say, anything above 1GHz is magic, anything below is DC
[17:10:54] <Jartza> also I think they use it for EMC-testing and stuff
[17:10:55] <jacekowski> lucikly i normally deal only with DC
[17:11:17] <Jartza> me too
[17:11:27] <Jartza> but I can still use the lecroy whenever it's free :)
[17:11:42] <Jartza> at least I don't have to worry about scope running out of bandwidth
[17:12:09] <Jartza> though it feels a bit like making a sin when measuring something like 5Mhz SPI with it
[17:12:18] <julius> theres a wow player called "leroy jenkins"
[17:12:38] <jacekowski> i wonder how many
https://www.youtube.com/watch?v=U3w_EWgGQuk of those do they sell
[17:12:54] <julius> he invented the "leroy jenkins move"
[17:13:04] <jacekowski> julius: yes
[17:13:17] <Jartza> jacekowski: wow. 100GHz :D
[17:13:37] <jacekowski> Jartza: million dollars
[17:13:43] <Jartza> piece of cake
[17:13:47] <Jartza> :)
[17:13:49] <jacekowski> i wonder how many do they sell
[17:13:52] <Jartza> no idea
[17:14:06] <Jartza> I don't know how much the customer has spent on measuring devices either
[17:14:44] <Jartza> I just know they just had one lecroy calibrated. a guy was flown in from switzerland with gazillion calibration thingies to do it.
[17:16:02] <learath> Jartza: really? wow. that sounds stupidly expensive.
[17:16:52] <Jartza> I think it's still cheaper than to ship the device itself and make sure it doesn't break while travelling
[17:17:04] <Jartza> because we all know how DHL/UPS/Fedex/et.al. throw their packages
[17:17:36] <jacekowski> but the only application i can see for a 100GHz scope is satellite shit
[17:17:54] <jacekowski> that normally runs with 15GHz+ signals
[17:17:55] <jacekowski> iirc
[17:31:50] <Jartza> I wouldn't know, I operate at sub-1G-range :D
