| 01:20.02 | *** join/#qi-hardware kristianpaul (~kristianp@unaffiliated/kristianpaul) |
| 01:35.21 | *** join/#qi-hardware arhuaco (~arhuaco__@181.61.60.85) |
| 01:38.01 | *** join/#qi-hardware fengling (~fengling@114.111.166.208) |
| 01:44.03 | *** join/#qi-hardware kristianpaul (~kristianp@181.137.226.143) |
| 01:44.03 | *** join/#qi-hardware kristianpaul (~kristianp@unaffiliated/kristianpaul) |
| 02:20.34 | *** join/#qi-hardware kristianpaul (~kristianp@181.137.226.143) |
| 02:20.34 | *** join/#qi-hardware kristianpaul (~kristianp@unaffiliated/kristianpaul) |
| 04:51.36 | *** join/#qi-hardware atommann (~atommann@58.251.2.94) |
| 05:33.07 | *** join/#qi-hardware xiangfu (~xiangfu@60.194.113.42) |
| 05:38.43 | wpwrak | xiangfu: nice pictures ! in Anelok-led-on.jpg, is that LED really on ? |
| 05:38.54 | wpwrak | also, in Anelok-wrong-usb-connector.jpg the connector looks good. are you sure this it the wrong one ? |
| 05:39.04 | xiangfu | wpwrak: Hi. I mean the oled was on. :) |
| 05:39.47 | wpwrak | aaah ! ;-) |
| 05:39.57 | xiangfu | wpwrak: the connector pin was not 100% match the pad. |
| 05:40.38 | wpwrak | did that cause a problem ? |
| 05:41.19 | wpwrak | it looks as if it should still work. though the leg hidden under the cable may be a bit close to the via |
| 05:42.00 | xiangfu | the connection is right. but the pin is not 100% match the PCB pad. |
| 05:42.42 | *** join/#qi-hardware valhalla (~valhalla@88-149-211-235.v4.ngi.it) |
| 05:43.08 | xiangfu | no. it works fine. and pretty stable. |
| 05:43.17 | wpwrak | ah well, details :) i'm not using the connector correctly anyway - there should be board cut-outs for the little "horns". of course, i noticed that only very late ... |
| 05:43.32 | xiangfu | next time I will find the ring connector. |
| 05:43.48 | xiangfu | ah. Yes. |
| 05:46.52 | wpwrak | by the way, i made some changes that may break things. 1) i fixed a bug in touch screen polling that - ironically - made it work. i'm still not entirely sure why it mattered, but it did. i also changed how the input system handles time, so that it should now be independent from delays elsewhere. but this may introduce surprises. my devices work fine with the new code, though, so hopefully i didn't do too much damage. |
| 05:48.40 | wpwrak | 2) i kicked out the non-open register definitions and linker script and replaced them with things i can legally redistribute. had to make some small changes for that, so i may have broken something. things look good here, though, so again there's hope that nothing bad will happen. just wanted to warn you. |
| 05:52.02 | xiangfu | I will test the new code. then let you know. |
| 05:54.17 | xiangfu | lunch time. |
| 05:54.50 | wpwrak | in general, the touch sensor driver will see more changes in the future: right now it polls actively which a) wastes quite a lot of energy, especially in standby, and b) makes its timing fairly chaotic. the above changes should already bring some sanity to input.c, but touch.c still needs more work. the idea is to make it interrupt-driven and then let the CPU enter a sleep mode when there's nothing else to do. all this means that the |
| 05:54.50 | wpwrak | characteristics of the touch sensor may change a bit. e.g., the threshold value and such may have to be adjusted at some point. |
| 06:34.12 | *** join/#qi-hardware porchaso0 (~quassel@218.33.140.164.eo.eaccess.ne.jp) |
| 07:10.12 | *** join/#qi-hardware fengling (~fengling@114.111.166.208) |
| 07:59.47 | *** join/#qi-hardware fengling (~fengling@125.39.68.34) |
| 08:17.01 | *** join/#qi-hardware wej (~j@2001:1af8:4010:a08c:1::6e) |
| 08:38.40 | *** join/#qi-hardware wolfspraul (~wolfsprau@brln-5f72ffa9.pool.mediaWays.net) |
| 08:39.59 | *** join/#qi-hardware pcercuei (~paul@137.71.226.54) |
| 09:48.32 | *** join/#qi-hardware xiangfu_ (~xiangfu@60.194.113.42) |
| 10:38.13 | *** join/#qi-hardware wej (~j@2001:1af8:4010:a027:21::4e) |
| 11:16.23 | DocScrutinizer05 | forget the particular schematics, but the service digikey offers here actually looks very smart: http://www.digikey.com/schemeit/#wp6 |
| 11:16.58 | DocScrutinizer05 | the idea is great anyway |
| 11:18.46 | DocScrutinizer05 | EDA as a web service, offered with component lib already |
| 11:25.45 | whitequark | >EDA as a web service |
| 11:26.07 | whitequark | and in a year they get acquihired and write you a message about "an incredible journey" you had together, and tell you they'll delete all your designs in a month |
| 11:26.15 | whitequark | http://ourincrediblejourney.tumblr.com/ |
| 11:28.00 | viric | :) |
| 11:28.13 | viric | I envision Xilinx software for the web |
| 11:28.34 | *** join/#qi-hardware fengling (~fengling@125.39.68.34) |
| 11:29.09 | whitequark | they'll get there eventually |
| 11:29.16 | viric | nice, this incredible journey |
| 11:29.22 | whitequark | but it'll be just same old shit, now in a web browser |
| 11:29.26 | whitequark | no innovation in EDA |
| 11:29.49 | viric | but you will be able to design from your iphone |
| 11:31.51 | eintopf | :D |
| 11:32.14 | eintopf | via iphone while sitting on the toilet! |
| 11:32.59 | whitequark | so that's why none of the iot devices work |
| 11:35.29 | eintopf | making iot stuff |
| 11:35.50 | eintopf | so my work doesn't work? Yea, it's mostly wip. |
| 11:38.46 | whitequark | eintopf: does your iot stuff depend on a central server provided by $COMPANY? |
| 11:39.03 | whitequark | does it stash a remotely exploitable ancient version of linux somewhere it's accessible by network? |
| 11:41.32 | eintopf | I improve the 802.15.4 /6lowpan stack in linux kernel to make it in some useable state |
| 11:41.45 | eintopf | all open source |
| 11:42.54 | eintopf | common solution with 6lowpan/802.15.4 is a contiki mcu as adaptation layer |
| 11:43.09 | eintopf | but, we want remove the contiki stuff |
| 11:43.24 | whitequark | yeah, contiki is terribad |
| 11:44.12 | *** join/#qi-hardware Akiraa (~Akiraa@unaffiliated/akiraa) |
| 11:45.42 | eintopf | whitequark: I also working on a contiki replacement. The goal is to have a easy development -> copy linux implemented IPv6 IoT application into the $CONTIKI_REPLACEMENT and just add it to the buildsystem |
| 11:45.53 | eintopf | I mean from userspace view, it should be the same interface |
| 11:46.10 | eintopf | also contains, Kconfig as builsystem and such things... like linux |
| 11:46.20 | eintopf | but this is my little hobby project |
| 11:47.12 | eintopf | first I want only add a "generic" firmware application for atusb, so we can also run the firmware on the RZUSBSTICK (it's something like atusb, but different mcu and at86rf230) |
| 11:47.48 | eintopf | then you need just replace two ".config" configs to making one atusb firmware and one RZUSBSTICK firmware |
| 11:47.55 | eintopf | but I will keep the name atusb firmware :) |
| 11:48.09 | eintopf | so, that are big plans... |
| 11:48.33 | Akiraa | hello, are you aware of ready-made solutions to implement a 'mass storage device' api for a device like 'banana pi' or olinuxino, boards that have USB-OTG |
| 11:48.55 | Akiraa | so that they may present themselves as 'removable storage' to computers or other USB hosts |
| 11:48.59 | whitequark | eintopf: lately i have been doubting how wise it is to put linux in iot devices |
| 11:49.17 | whitequark | heartbleed, right? basically none embedded devices with heartbleed will ever get patched |
| 11:49.35 | whitequark | and if we find an exploitable vulnerability in the network stack, it's going to be an apocalypse, pretty much |
| 11:49.45 | whitequark | s/if/when/ really |
| 11:49.46 | qi-bot | whitequark meant: "and when we find an exploitable vulnerability in the network stack, it's going to be an apocalypse, pretty much" |
| 11:49.53 | eintopf | whitequark: time will changes and for a IPv6<->6LoWPAN bridge is linux the best solution |
| 11:50.08 | eintopf | and thats a stationary nodes with power connection |
| 11:50.30 | Akiraa | whitequark: regardless, IoT devices are too low power to survive attacks if hooked directly to the internet, they require a separate box to act as a firewall, rate-limiter, load-balancer etc. |
| 11:50.34 | whitequark | how many routers get vendor firmware updates? |
| 11:50.47 | whitequark | how many vendor firmwares aren't horribly vulnerable by themselves? |
| 11:51.29 | whitequark | Akiraa: well, most iot devices i have seen so far are pretty big. think nest thermostat or smoke |
| 11:51.41 | whitequark | that's a full-fledged linux board. the immediate future will be dominated by this form |
| 11:52.02 | Akiraa | they are expensive enough to have a fully powered CPU inside that can handle crypto, I guess, but wouldn't bet on it |
| 11:52.28 | whitequark | well, you /have/ to handle crypto in /any/ wireless device, it's not even a question, but this is not what i am talking about |
| 11:52.36 | whitequark | they use arm boards running linux and openssl and all that |
| 11:52.59 | whitequark | and that doesn't help |
| 11:53.25 | eintopf | these devices does exists already, atheros sells arm socs with integradted 802.11 |
| 11:53.34 | eintopf | I want something like that, but with 802.15.4 |
| 11:53.54 | eintopf | with ~4MB flash |
| 11:54.03 | eintopf | such things, all is in one chip |
| 11:54.34 | eintopf | but do really power managment with very low power and via battery... |
| 11:54.59 | eintopf | don't know how possible that is currently |
| 11:56.40 | Akiraa | I would be interested even in some useful keywords for search if you can help (implementing USB "mass storage device" from a linux box with USB-OTG) |
| 12:31.01 | *** join/#qi-hardware fengling (~fengling@125.39.68.34) |
| 12:49.56 | *** join/#qi-hardware kristianpaul (~kristianp@unaffiliated/kristianpaul) |
| 13:10.10 | *** join/#qi-hardware Akiraa (~Akira@unaffiliated/akiraa) |
| 13:19.42 | *** join/#qi-hardware fengling (~fengling@125.39.68.34) |
| 13:21.51 | wpwrak | Akiraa: g_file_storage seems to be what you're looking for. (search term linux gadget mass storage) |
| 13:23.04 | wpwrak | whitequark: (web-based EDA) we also have mbed, so also sw engineers can work the modern way :) |
| 13:24.15 | wpwrak | and haven't we come a long way ? from SaaS (whatever-S-was-as-a-Service) to X-a-a-S *(Whatever-as-a-Service) now to YJaaS (Your-Job-...), all the way building up to YCaaS (Your Company) |
| 13:24.55 | wpwrak | thinking of it, the mafia selling protection and vandalism insurance did some quite pioneering work in that domain :) |
| 13:30.20 | Akiraa | wpwrak: thanks |
| 13:35.06 | *** join/#qi-hardware FDCX (~fdcx@2a02:2f0a:a03f:ffff::50c:7ca4) |
| 13:58.48 | *** part/#qi-hardware woakas (~woakas@static.13.240.46.78.clients.your-server.de) |
| 14:25.35 | whitequark | lol |
| 14:25.45 | DocScrutinizer05 | 4 new snapshots about BPW34: http://neo900.org/stuff/joerg/random-media/IR-photodiode/BPW34+1kR_electron-flash-1m-dist.jpg http://neo900.org/stuff/joerg/random-media/IR-photodiode/* |
| 14:29.55 | DocScrutinizer05 | the funny stray signal at start of http://neo900.org/stuff/joerg/random-media/IR-photodiode/BPW34+1kR_electron-flash_detail2us_rise.jpg is prolly via inductive or capacitive interference from camera to the 5cm GND wire of the probe |
| 14:30.53 | DocScrutinizer05 | most likely inductive, by the trigger inductor that creates high voltage to trigger electrode of electron flash tube |
| 14:36.32 | DocScrutinizer05 | sidenote: the BPW provides an incredible 25mW power from a tiny electron flash fired ~10cm distant from it |
| 14:37.55 | DocScrutinizer05 | even with the aleggedly "1m dist" which actually rather been 60cm, in http://neo900.org/stuff/joerg/random-media/IR-photodiode/BPW34+1kR_electron-flash-1m-dist.jpg |
| 14:38.20 | wpwrak | next: "wireless charging" :-) |
| 14:39.18 | DocScrutinizer05 | for 10cm ( http://neo900.org/stuff/joerg/random-media/IR-photodiode/BPW34+1kR_electron-flash.jpg ) it's even 49mW |
| 14:40.30 | DocScrutinizer05 | well, I guess you can calculate the distance ratio from power ratio more accurate than my guesstimations |
| 14:41.11 | DocScrutinizer05 | I bet it's exactly the radiation-power / area * efficiency |
| 14:41.35 | wpwrak | that would indeed kinda make sense :) |
| 14:42.09 | DocScrutinizer05 | but the camera has a way to modulate flash power. Dunno how it does that |
| 14:42.45 | DocScrutinizer05 | anyway SEVEN volt!! |
| 14:43.18 | DocScrutinizer05 | now you see why they test photovoltaic panels in factory with strong electron flashlight |
| 14:44.26 | DocScrutinizer05 | I guess on defective PV panels some traces simply will burn out |
| 14:44.55 | DocScrutinizer05 | afk |
| 14:45.24 | wpwrak | it's good to know that the panels will be able to resist the sun going supernova, just in case :) |
| 14:46.26 | wpwrak | the aftermath will be messy enough. i guess the panel makers wouldn't want to have to worry about warranty claims on top of it, too |
| 14:46.52 | DocScrutinizer05 | thunder lighting |
| 14:47.27 | DocScrutinizer05 | fireworks |
| 14:48.01 | wpwrak | you must have quite some fireworks ;-) |
| 14:49.15 | DocScrutinizer05 | there exists quite some fireworks, yes |
| 14:50.03 | DocScrutinizer05 | some of those 20cm diameter bombs are filled with flash power |
| 14:50.23 | DocScrutinizer05 | well, maybe 12cm only |
| 14:52.28 | eintopf | z/win 3 |
| 14:52.31 | eintopf | oops |
| 14:52.39 | eintopf | I meant win 300 |
| 14:52.48 | eintopf | just for clarify |
| 14:57.16 | *** join/#qi-hardware kristianpaul (~kristianp@181.137.226.143) |
| 14:57.16 | *** join/#qi-hardware kristianpaul (~kristianp@unaffiliated/kristianpaul) |
| 15:08.11 | DocScrutinizer05 | hmmm http://www.elektronik-labor.de/Projekte/Alpha.html |
| 15:14.40 | eintopf | DocScrutinizer05: why do you need something like that? |
| 15:15.01 | DocScrutinizer05 | just pondering synergies |
| 15:15.47 | eintopf | wahhh, the guy hold a radioactive clock |
| 15:15.53 | DocScrutinizer05 | yeah |
| 15:16.59 | DocScrutinizer05 | well, the girls who painted the phosphorescent paint on the clock hands formed their brushes by licking them ;-o |
| 15:17.47 | DocScrutinizer05 | no surprise they _all_ died during max 10 years iirc |
| 15:18.21 | eintopf | DocScrutinizer05: do you think in moscow is the radioactive higher than in... germany? |
| 15:18.38 | DocScrutinizer05 | no, why? |
| 15:19.03 | eintopf | don't know, maybe because it's easier to get radioactive material |
| 15:19.19 | eintopf | (don't know if this is true) |
| 15:19.48 | DocScrutinizer05 | well, the _total_ average radioactivity, incl all hotspots, even shielded ones, for sure is higher |
| 15:20.26 | DocScrutinizer05 | for 99.999% of normal places though I don't think there's a significant difference |
| 15:20.46 | eintopf | ah, ok. |
| 15:22.23 | DocScrutinizer05 | in germany we have quite some vaiance in average environmental radioactivity too. Thanks to Chernobyl fallout which hit mostly Bayern |
| 15:22.37 | whitequark | moscow underground uses quite a bit of granite |
| 15:22.51 | DocScrutinizer05 | yeah, there might be Radon |
| 15:23.02 | pcercuei | < DocScrutinizer05> in germany we have quite some vaiance in average environmental radioactivity too. Thanks to Chernobyl fallout which hit mostly Bayern |
| 15:23.12 | pcercuei | now everything suddently makes sense :) |
| 15:23.27 | eintopf | ahh, I know radon. You can use it for measurement time? |
| 15:23.46 | eintopf | instead of quarz |
| 15:23.54 | whitequark | no |
| 15:23.55 | DocScrutinizer05 | hmm? |
| 15:24.04 | whitequark | atomic clocks do not use radioactivity |
| 15:24.15 | eintopf | mhhh |
| 15:24.18 | DocScrutinizer05 | they work like a microwave oven |
| 15:24.33 | whitequark | they use... basically resonance of the nucleus of some elements, cesium usually |
| 15:24.36 | DocScrutinizer05 | filled with vapor of usually Caesium |
| 15:25.08 | eintopf | yes, caesium... but there exists something between caesium and quarz. Something with R... |
| 15:25.09 | whitequark | so the thing is, the nucleus of caesium has spin, and that spin can flip, and flipping it takes a very small and also very consistent amount of energy |
| 15:25.12 | eintopf | other material |
| 15:25.22 | whitequark | which happens to be in microwave range |
| 15:25.25 | DocScrutinizer05 | aaah maybe |
| 15:25.34 | whitequark | so you can use that difference as a frequency standard |
| 15:25.45 | DocScrutinizer05 | some weird stuff, yes I seem to remember, Notr Raduim. Ruthenium? |
| 15:25.52 | whitequark | rubidium |
| 15:26.00 | DocScrutinizer05 | ta |
| 15:26.00 | eintopf | yeaa rubidium |
| 15:26.25 | eintopf | I know some guys sells that on ebay |
| 15:26.38 | whitequark | it's just an alkali metal |
| 15:26.44 | DocScrutinizer05 | well, it's maybe something pretty "normal" |
| 15:26.54 | whitequark | it catches fire in air |
| 15:27.02 | whitequark | otherwise nothing very interesting about it |
| 15:27.03 | DocScrutinizer05 | like alkaline |
| 15:27.22 | whitequark | now what /is/ interesting is chip-scale atomic clocks |
| 15:27.23 | whitequark | MEMS |
| 15:27.28 | whitequark | for use in GPS chipsets |
| 15:27.40 | DocScrutinizer05 | hah |
| 15:27.41 | whitequark | http://www.microsemi.com/products/timing-synchronization-systems/embedded-timing-solutions/components/sa-45s-chip-scale-atomic-clock |
| 15:27.44 | whitequark | commercially available |
| 15:27.49 | DocScrutinizer05 | wow |
| 15:28.03 | eintopf | :o |
| 15:28.23 | eintopf | indoor gps comes possible |
| 15:28.34 | whitequark | not really |
| 15:28.45 | eintopf | ah, ok. |
| 15:28.47 | whitequark | what this makes possible is instant fix |
| 15:28.50 | whitequark | and more precision |
| 15:28.52 | DocScrutinizer05 | indoor is not related to timebase |
| 15:29.03 | whitequark | i've seen a fun paper about indoor |
| 15:29.10 | whitequark | using MIMO receiver to fingerprint various locations |
| 15:29.25 | whitequark | i.e. NOT triangulation, that doesn't take into account multipath |
| 15:29.30 | eintopf | I know the solution to use RF and ultrasonic |
| 15:29.31 | DocScrutinizer05 | 35g. 17cm^3. I wonder how many bucks |
| 15:29.39 | whitequark | rather this one /depends/ on multipath propagation to make fingerprints unique |
| 15:29.43 | eintopf | to measurement the ultrasonic wave traveling time |
| 15:29.52 | whitequark | eintopf: that's not really used |
| 15:30.06 | eintopf | yea, but works in labor enviornment |
| 15:30.19 | whitequark | well, if you need to measure a meter or two, sure |
| 15:30.23 | DocScrutinizer05 | whitequark: hehe, sounds like what I started in part1 of "GPS revised" |
| 15:30.27 | whitequark | but there are indoor positioning systems for warehouses |
| 15:30.52 | eintopf | RFID marks on the floor? |
| 15:30.56 | DocScrutinizer05 | http://lists.openmoko.org/pipermail/openmoko-kernel/2008-April/002434.html |
| 15:31.03 | whitequark | eintopf: that's a cheap way yes |
| 15:31.34 | whitequark | barcodes on the ceiling |
| 15:31.37 | whitequark | if you are REALLY cheap |
| 15:31.46 | eintopf | https://www.youtube.com/watch?v=quWFjS3Ci7A |
| 15:31.48 | whitequark | or you could use http://www.mit.edu/people/jhow/papers/Prigge_thesis_draft.pdf |
| 15:31.52 | eintopf | you mean something like this? |
| 15:32.54 | DocScrutinizer05 | >>Front of OM Ap. building, 3m away<< |
| 15:33.18 | DocScrutinizer05 | that's the concept of highres-fingerprinting, done by me in 2008 |
| 15:33.25 | eintopf | I make a bookmark to the thesis, thanks |
| 15:34.47 | DocScrutinizer05 | >>The max and min readings where obtained by moving the phone ~60cm!<< |
| 15:36.02 | DocScrutinizer05 | once you got a "map" of your location fingerprints, you can even do pattern matching as soon as your receiver is moving |
| 15:36.30 | DocScrutinizer05 | assuming there will never be jumps / teleports from ne location to another |
| 15:37.56 | DocScrutinizer05 | assuming further that movement usually is mostly linear, you can check the sample pattern against plausible fottprint pattern sequences |
| 15:39.53 | DocScrutinizer05 | but the most reliable and simple indoor location is U-TDOA done with e.g. WLAN |
| 15:40.49 | whitequark | don't you need many access points for that? |
| 15:40.54 | DocScrutinizer05 | when you're the location owner and want to locate "arbitrary" visitors that happen to have a WLAN-enabled device with them |
| 15:40.55 | whitequark | with precisely synchronized clocks |
| 15:41.06 | DocScrutinizer05 | wpwrak: yes |
| 15:46.51 | DocScrutinizer05 | the E-OTD-alike "fingerprinting" by calculation of reflexion/multipath phase to original signal needs pretty specialized receivers |
| 15:46.52 | DocScrutinizer05 | U-TDOA nees specialized APs |
| 15:46.56 | DocScrutinizer05 | poor man's E-OTD like in http://lists.openmoko.org/pipermail/openmoko-kernel/2008-April/002434.html relies on interference between direct and multipath signal creating local standing waves that modulate signal aplitude over distances in the range a a few dozen or hundred wavelengths |
| 15:47.03 | DocScrutinizer05 | you also need several distinct stationary transmitters for that |
| 15:49.13 | DocScrutinizer05 | downside: such standing-wave-interferences are very unstable, they change a lot with every change in environment, like different temperature or air humidity |
| 15:49.58 | DocScrutinizer05 | s/wprak/whitequark/ sorry |
| 15:52.25 | whitequark | yeah |
| 15:53.35 | whitequark | relevant: http://hackaday.com/2015/02/17/mapping-wifi-signals-in-3-dimensions |
| 15:53.38 | DocScrutinizer05 | U-TDOA is the method of choice. And for smartphones many carriers already offer location detection assisted by U-TDOA |
| 15:55.09 | DocScrutinizer05 | UMTS--U-TDOA works fine indoors, and incredibly fast too. My N900 meanwhile gets a location fix during no more than 4s no matter where I am |
| 15:55.23 | DocScrutinizer05 | cold |
| 15:56.05 | DocScrutinizer05 | thanks to the GPS controlled by the modem |
| 15:57.01 | DocScrutinizer05 | ~rrlp |
| 15:57.01 | infobot | rrlp is, like, the Radio Resource LCS (Location Service) Protocol as specified first in GSM TS 04.31, or http://security.osmocom.org/trac/wiki/RRLP |
| 16:01.46 | DocScrutinizer05 | I didn't look into the RRLP detals but I guess there must be info from BTS to MT about the actual location of MT as seen by "the network" - in addition to the mere A-GPS "raw" data about which codes to check for at which frequency |
| 16:05.14 | DocScrutinizer05 | so the N900 GPS gets enabled, the modem controlling the GPS asks network for RRLP assistance, network does a U-TDOA trilateration and sends the info with a estimated horizontal precision of maybe 10 or 20m back to the modem, which then decides this is already a nice "first fix" even when GPS has not yet correlated to the SVs |
| 16:05.47 | DocScrutinizer05 | (this is _my_ semi-educated guess on what's going on) |
| 16:07.47 | DocScrutinizer05 | quite possible that carriers do U-TDOA for _all_ MT they service, by default, nowadays |
| 16:07.53 | DocScrutinizer05 | all the time |
| 16:09.55 | DocScrutinizer05 | why waste a transmission? why delay stuff when you can do it in advance already, so to speed up LCS |
| 16:17.17 | DocScrutinizer05 | and it's known the TLA agencies run their own independent U-TDOA networks, I just wonder about the bandwidth of RX bands they receive and record with timestamp for later computations when they are interested in a particular transmitter's exact position |
| 16:18.55 | whitequark | they seem to be using stingrays actually |
| 16:19.13 | DocScrutinizer05 | what's a stingray? |
| 16:19.17 | whitequark | fake BTS |
| 16:19.26 | DocScrutinizer05 | well, yes, that too |
| 16:19.28 | whitequark | used for intercepting calls / SMS / locating |
| 16:19.35 | DocScrutinizer05 | just to crack encryption |
| 16:19.56 | DocScrutinizer05 | when they want to eavesdrop on a particular communication |
| 16:19.56 | whitequark | i doubt they'd use stingrays, which are relatively easily detected by public, instead of proper U-TDOA if they could |
| 16:20.25 | DocScrutinizer05 | U-TDOA only records, it doesn't do MITM |
| 16:20.41 | DocScrutinizer05 | so encryption is effective in the U-TDOA records |
| 16:20.46 | whitequark | well you can do any MITM you want using the network as well as a stingray |
| 16:20.56 | DocScrutinizer05 | as long as it's effective at all |
| 16:21.47 | DocScrutinizer05 | the purpose of U_TDOA is completely different than that of an IMSI-catcher anyway |
| 16:23.11 | DocScrutinizer05 | and actually I guess only the "poor folks" like regular law enforcement still use IMSI-catchers. The mighty TLA's use direct interception interface of the carriers |
| 16:23.49 | DocScrutinizer05 | U-TDOA however is not limited to cellphones |
| 16:24.11 | DocScrutinizer05 | they can trilaterate virtually every RF-device |
| 16:25.33 | DocScrutinizer05 | and prolly not only real-time but alsio from records, for at least hours back |
| 16:29.43 | DocScrutinizer05 | only need to know the signal signature |
| 16:32.26 | DocScrutinizer05 | I wonder if they already record the complete spectrum from say 50kHz to 4GHz |
| 16:32.55 | DocScrutinizer05 | prolly long wave is useless for U-TDOA |
| 16:33.40 | *** join/#qi-hardware Jay7 (jay@176.15.162.54) |
| 16:33.52 | DocScrutinizer05 | since U-TDOA by physics can't go significantly more accurate than a fraction of wavelength |
| 16:34.30 | whitequark | what if you also record phase? |
| 16:35.03 | DocScrutinizer05 | that's why I say "fraction of wavelength" |
| 16:35.18 | DocScrutinizer05 | you can't record phase to arbitrary precision |
| 16:35.37 | DocScrutinizer05 | sort of RF Heissenberg |
| 16:36.54 | DocScrutinizer05 | anyway assume they'd sample 16bit at 8G-samples/s |
| 16:37.09 | DocScrutinizer05 | that's a "ridiculous" 16GB/s |
| 16:37.25 | DocScrutinizer05 | and somewhat covers 0...4GHz |
| 16:39.04 | DocScrutinizer05 | 16bit logarithmic would prolly also yield sufficient precision as well as sensitivity |
| 16:39.20 | DocScrutinizer05 | if not, go 24 or even 32 |
| 16:40.28 | DocScrutinizer05 | place a grid of such "total receivers" evenly spaced over a country, grid pitch of maybe 50 or 100km |
| 16:41.13 | DocScrutinizer05 | record *all* transmitting devices, incl location down to 10m precision |
| 16:42.31 | DocScrutinizer05 | data volume in the 1digit TB per minte range, per station |
| 16:43.14 | DocScrutinizer05 | how many 2TB HDDs will they spend on that? |
| 16:43.44 | DocScrutinizer05 | are a 1000 per station reasonable? |
| 16:46.02 | DocScrutinizer05 | (long wave) even for 100kHz the wavelength is 2.7km if my math doesn't suck |
| 16:46.36 | whitequark | 10PB per week per station |
| 16:46.45 | whitequark | 1000 HDDs per station is a LOT |
| 16:47.03 | whitequark | that would be a substantial part of global production |
| 16:47.05 | DocScrutinizer05 | 1000 a lot? why? |
| 16:47.13 | DocScrutinizer05 | nah |
| 16:48.08 | DocScrutinizer05 | if somebody uses a significant fraction of global HDD production then that's the NSA data vcenter in... err Utah? |
| 16:49.01 | whitequark | yeah |
| 16:49.33 | DocScrutinizer05 | for germany you would prolly get away with some 2 digit number of stations, that would sum up to maybe 80k HDD. Samsumg sells more laptops every day |
| 16:51.31 | DocScrutinizer05 | and I bet my scratchpad design can get significantly streamlined by some network engineers |
| 16:52.17 | DocScrutinizer05 | and some smart math cracks to apply data compression and whatnot |
| 16:54.08 | DocScrutinizer05 | nd maybe they do snapshots whenever something worrying happens |
| 16:55.27 | whitequark | ha |
| 16:55.29 | whitequark | snapshots |
| 16:55.45 | whitequark | the only way you can do snapshots with this amount of data is physically moving hard drives around |
| 16:55.49 | DocScrutinizer05 | well, call it "freeze" |
| 16:55.50 | whitequark | nothing else comes close |
| 16:55.58 | whitequark | in bandwidth |
| 16:56.14 | whitequark | amazon offers a backup service where they record backup on HDDs and mail them you |
| 16:56.32 | DocScrutinizer05 | and yes, I actually expect them to carry those HDD arounf in racks a 128 each |
| 16:58.42 | DocScrutinizer05 | some guy pushes a button for station 2,3,4,18,19,20. A 2h later a lorry with spare racks drives by each of those 6 stations and some guys swap the new racks for the snapshotted ones |
| 16:59.49 | DocScrutinizer05 | the poor noob is the one to carry the 8 new racks up to 3rd floor and the ones with the data down to the lorry |
| 17:02.01 | DocScrutinizer05 | nothing comes close to the bandwidth of a lorry full of HDD |
| 17:02.55 | DocScrutinizer05 | poor RTT but mega bandwidth ;-) |
| 17:04.50 | DocScrutinizer05 | but hey, connect the stations with decent DSL to make a grid of distributed computing and analyze the data without moving it around in lorries |
| 17:05.45 | DocScrutinizer05 | after all you're not interested in the complete set of raw data, only in a very specific negligible part of it |
| 17:06.39 | DocScrutinizer05 | so as long as the stations have sufficient spare HDD for the next snapshot/freeze, no need to supply them with swap racks |
| 17:09.40 | DocScrutinizer05 | a simple calculation: you want to save or swap or process the spare set of HDD with that snapshot before the HDD set in charge to store new data is filled up |
| 17:10.46 | DocScrutinizer05 | unless you got a 3rd set of HDD, aka a 2nd spare |
| 17:18.47 | DocScrutinizer05 | anyway consider *total* radio surveillance a fact |
| 17:19.09 | whitequark | a fact is way too strong. it's a possibility |
| 17:19.21 | whitequark | it's entirely possible that it doesn't offer enough return for the (substantial) investment |
| 17:19.45 | DocScrutinizer05 | in that context I consider everything faintly possible a given fact and already accomplished |
| 17:20.20 | whitequark | so, where's our cold fusion plants? |
| 17:20.30 | DocScrutinizer05 | the investment is negligible for the return |
| 17:20.34 | whitequark | or even hot fusion :] |
| 17:20.47 | DocScrutinizer05 | how, that context? |
| 17:21.10 | DocScrutinizer05 | to supply NSA with electricity? |
| 17:22.03 | DocScrutinizer05 | and you forgot that fusion is not even theoretically stable yet |
| 17:22.22 | DocScrutinizer05 | they hope to make it *work* in maybe 20 years or so |
| 17:22.43 | DocScrutinizer05 | a 0..8GHz RF scanner is "available on ebay" |
| 17:23.15 | DocScrutinizer05 | and expense for one station is prolly significantly < 1 million |
| 17:23.23 | DocScrutinizer05 | that's peanuts for those guys |
| 17:24.18 | DocScrutinizer05 | particularly when return benefit is "total TF surveillance". They'd pay 1000 times as much for that |
| 17:24.38 | DocScrutinizer05 | s/ TF / RF / |
| 17:24.39 | qi-bot | DocScrutinizer05 meant: "particularly when return benefit is "total RF surveillance". They'd pay 1000 times as much for that" |
| 17:24.59 | whitequark | hard drives: $80,000 |
| 17:25.02 | whitequark | yeah sounds about right |
| 17:30.16 | *** join/#qi-hardware wej (~j@2001:1af8:4010:a027:21::4e) |
| 17:42.33 | *** join/#qi-hardware Haswell (~Haswell@unaffiliated/haswell) |
| 17:44.32 | DocScrutinizer05 | http://www.mit.edu/people/jhow/papers/Prigge_thesis_draft.pdf >> I certify that I have read this dissertation and that, in my opinion, it is fully adequate in scope and quality as a dissertation for the degree of **Doctor of Philosophy.**<< Oh WOW, what PHILOSOPHY Doctors deal with, incredible |
| 17:44.54 | whitequark | PhD |
| 17:45.10 | whitequark | means Doctor of Philosophy |
| 17:45.14 | whitequark | regardless of the actual domain |
| 17:49.11 | wpwrak | cf. "natural philosophy" :) |
| 17:58.43 | *** join/#qi-hardware wolfspraul (~wolfsprau@x2f75fb2.dyn.telefonica.de) |
| 18:02.28 | DocScrutinizer05 | I guess I'm spoiled by the very precise german nomenclature regarding academic degrees, and the bad reputation _our_ philosophy graduates have, regarding their perspective and usefulness for real life |
| 18:03.42 | DocScrutinizer05 | nevr heard of "natural philosophy" |
| 18:06.27 | DocScrutinizer05 | (very precise) well until recently they introduced all that "bachelor" (SIC)and whatnot stuff |
| 18:09.03 | wpwrak | they have perspectives ? :) |
| 18:11.59 | wpwrak | (nat. phil.) -> wikipedia. and it seems that you haven't read the fine works of Neal Stephenson :) |
| 18:13.01 | *** join/#qi-hardware pcercuei (~pcercuei@2a02:810d:1b40:1118::4) |
| 18:23.19 | DocScrutinizer05 | >>Deutschland: Dr. rer. nat. für lateinisch doctor rerum naturalium<< |
| 18:23.40 | DocScrutinizer05 | http://de.wikipedia.org/w/index.php?title=Spezial%3ASuche&profile=default&search=+phil.+nat.&fulltext=Search |
| 18:24.16 | DocScrutinizer05 | http://de.wikipedia.org/wiki/Doktor_der_Naturwissenschaften |
| 18:24.32 | DocScrutinizer05 | this? |
| 18:29.44 | DocScrutinizer05 | anyway seems I confused PhD with Dr. phil. |
| 18:31.28 | whitequark | no you did not |
| 18:31.28 | whitequark | https://en.wikipedia.org/wiki/Doctor_of_Philosophy |
| 18:31.33 | whitequark | "Doctor of Philosophy, abbreviated as PhD," |
| 18:31.59 | DocScrutinizer05 | Ohhh >>Dr. phil. nat. (philosophiae naturalis): Doktor der Naturwissenschaften, wie er an der Johann-Wolfgang-Goethe-Universität Frankfurt am Main anstelle des Dr. rer. nat. verliehen wird.<< |
| 18:32.02 | wpwrak | the german and the anglosaxon system are different |
| 18:33.05 | wpwrak | the anglosaxon system is basically based on the scientific culture of ancient greece, where all the "scientists" (as opposed to craftsmen) where "philosophers" |
| 18:33.40 | DocScrutinizer05 | in Germany Philosophers are hardly scientists at all ;-) |
| 18:34.01 | wpwrak | (dr. phil. nat.) of course, no rule without exception ;-) |
| 18:34.18 | DocScrutinizer05 | didn't know of that |
| 18:34.55 | DocScrutinizer05 | anglo PhD == german Dr. |
| 18:35.03 | DocScrutinizer05 | roughly |
| 18:35.39 | DocScrutinizer05 | german Dr. phil. ~= PhD of Philosophy |
| 18:35.42 | DocScrutinizer05 | or whatever |
| 18:36.18 | wpwrak | yes, they're equivalent. but the PhD comes from the origins of modern science in england, which in turn - that being the renaissance - adopted greek terminology |
| 18:36.50 | DocScrutinizer05 | while Germany didn't (except Johann-Wolfgang-Goethe-Universität) |
| 18:37.41 | wpwrak | the german "dr." probably just shed the "phil." at some point |
| 18:38.17 | *** join/#qi-hardware rejon (~rejon@223.17.157.191) |
| 18:38.28 | DocScrutinizer05 | whatever, puzzled me |
| 18:38.57 | DocScrutinizer05 | here Doctors of Philosophy usually end as taxi drivers |
| 18:40.17 | wpwrak | surely a great place to discuss weighty matters of the universe - and all that transcends it - with a diverse audience |
| 18:41.55 | DocScrutinizer05 | hehe, yes |
| 18:42.41 | DocScrutinizer05 | some make it into an occasional TV show |
| 18:42.47 | DocScrutinizer05 | talk shaw ;-D |
| 18:42.52 | DocScrutinizer05 | show* |
| 18:43.32 | DocScrutinizer05 | industry anyway rarely ever pays for their living |
| 18:44.28 | DocScrutinizer05 | and I'd feel scared when they now started messing with engineering topics |
| 18:45.28 | wpwrak | some of the more meandering standards could come from this sort of branch of society ... |
| 18:45.39 | DocScrutinizer05 | lol |
| 18:45.49 | DocScrutinizer05 | yes, USB for example |
| 18:46.16 | wpwrak | they provide the structural discourse, some engineering grunts get to fill in the numbers |
| 18:47.43 | DocScrutinizer05 | the only plausble explanation for stuff like CARKIT |
| 18:48.45 | DocScrutinizer05 | OSI also sounded like that sort of thing |
| 18:48.55 | wpwrak | i'd attribute this more to the easy availability of cheap glue :) |
| 18:49.08 | wpwrak | (carkit, that is. osi, itu, etsi, .. yes) |
| 18:50.12 | DocScrutinizer05 | oooh, now that took until the glue pun arrived. Oh yes, that's the better explanation |
| 18:51.57 | DocScrutinizer05 | never again will get that glue out of the USB jack |
| 18:52.37 | DocScrutinizer05 | might need to open up an Edding pen and see what it smells like |
| 18:52.53 | wpwrak | enjoy the trip ! :) |
| 18:56.26 | DocScrutinizer05 | returning to previous monologue, I wonder if there already are digital frontend receivers available, i.e. stuff that digitizes directly after antenna and does all further signal processing digitally |
| 19:23.18 | DocScrutinizer05 | I'm not even sure if some spectrum analyzers maybe work that way |
| 19:27.44 | whitequark | I believe satellite receivers almost work that way |
| 19:29.09 | whitequark | they digitize the IF signal, not original |
| 19:30.37 | DocScrutinizer05 | well, the IF still is some 2GHz, right? |
| 19:30.41 | whitequark | yes |
| 19:31.50 | DocScrutinizer05 | I guess what's a major roadblock for doing this sort of stuff on plain direct RF is the AGC you find in any conventional receiver |
| 19:32.20 | DocScrutinizer05 | a front end digitizer would need a dynamic range of... well some 80 or 90 dB |
| 19:33.52 | DocScrutinizer05 | I wonder if the SAT LNBs have AGC built in |
| 19:34.14 | whitequark | LNB? |
| 19:34.19 | whitequark | oh |
| 19:34.23 | DocScrutinizer05 | Low Noise Block(?) |
| 19:34.30 | whitequark | "low-noise block downconverter" |
| 19:36.24 | DocScrutinizer05 | also SAT signals are relatively "clean" |
| 19:36.53 | DocScrutinizer05 | i.e. no far off signals of high amplitude |
| 19:37.18 | DocScrutinizer05 | the LNB already filters all that out |
| 19:39.02 | DocScrutinizer05 | a - say - terrestrial digital frontend receiver would have to cope with signals that are maybe 80 below the "noise" from a nearby broadcast station |
| 19:41.42 | DocScrutinizer05 | and since we don't do any filtering before ADC in our simple all digital design, all that "noise" (which actually is a valid signal as well, for above discussed total surveillance receiver) needs to get digitized as well, while not covering and garbling very weak signals |
| 19:42.24 | DocScrutinizer05 | so yes, the ADC for such a receiver will need quite a dynamic range and will cost a few bucks |
| 19:46.59 | DocScrutinizer05 | simply switching off the LO in RTL2832 dongle should turn it into a shortwave receiver with frontend digitizing. Would need to remove any highpass filters in input though |
| 19:47.39 | DocScrutinizer05 | I think some guys already did this |
| 19:55.03 | DocScrutinizer05 | anyway with such evidently feasible ~20Mhz upper freq digital frontend receiver, you could already receive _all_ shortwave broadcast with just one computer and store it to your HDD, and later on "tune in" to whatever broadcast station you like on that stored data |
| 19:56.23 | DocScrutinizer05 | s/_all_/concurrently, simultaneously _all_/ |
| 19:56.24 | qi-bot | DocScrutinizer05 meant: "anyway with such evidently feasible ~20Mhz upper freq digital frontend receiver, you could already receive concurrently, simultaneously _all_ shortwave broadcast with just one computer and store it to your HDD, and later on "tune in" to whatever broadcast station you like on that stored data" |
| 19:56.28 | *** join/#qi-hardware wej (~j@2001:1af8:4010:a027:21::4e) |
| 20:14.57 | *** join/#qi-hardware wej (~j@2001:1af8:4010:a027:21::4e) |
| 20:28.32 | *** join/#qi-hardware wej (~j@2001:1af8:4010:a027:21::4e) |
| 22:13.05 | *** join/#qi-hardware wej (~j@2001:1af8:4010:a027:21::4e) |
| 23:03.39 | *** join/#qi-hardware wej (~j@2001:1af8:4010:a027:21::4e) |
| 23:33.40 | *** join/#qi-hardware wej (~j@2001:1af8:4010:a027:21::4e) |
