| Ayla | would USB-over-GPIO be possible? | 01:03 |
|---|---|---|
| wpwrak | yes :) http://www.obdev.at/avrusb/ | 01:06 |
| Ayla | ah, I was thinking about a linux driver | 01:07 |
| Ayla | still interesting | 01:07 |
| whitequark | wpwrak: it's USB device, not host | 01:08 |
| whitequark | through, on one hand, that matters much less for FPGA | 01:08 |
| whitequark | and on other, I don't know of working, more or less finished USB2.0 cores | 01:08 |
| wpwrak | whitequark: Ayla didn't specify whether device or host :) | 01:08 |
| whitequark | I guessed from the context | 01:09 |
| Ayla | host :) | 01:09 |
| whitequark | ah wait, that's not #mm | 01:09 |
| qi-bot | [commit] Xiangfu Liu: pick-pdf script file. thanks jiri.brozovsky (master) http://qi-hw.com/p/openwrt-packages/168c076 | 02:35 |
| qi-bot | [commit] Xiangfu Liu: pick-pdf add Version, add -type f to find, exit when no pdf file found (master) http://qi-hw.com/p/openwrt-packages/441bd7e | 02:35 |
| qi-bot | [commit] Xiangfu: nanonote: add bard icon (master) http://qi-hw.com/p/gmenu2x/63f7e54 | 02:37 |
| qi-bot | [commit] Xiangfu: nanonote: add pickpdf icon (master) http://qi-hw.com/p/gmenu2x/78b6070 | 02:37 |
| whitequark | I strongly advice you to never, ever, try to apply that "one-line" patch on a production server when you are sleep-deprived. | 13:10 |
| whitequark | it WILL FAIL. | 13:10 |
| whitequark | catastrophically. | 13:10 |
| Action: whitequark has just barely recovered a billing db after such a "patch" | 13:13 | |
| wpwrak | DocScrutinizer: a few days ago, you were bragging that one could retrieve bar code data even from under an insane amount of noise. this got me wondering: | 17:08 |
| wpwrak | if you displayed some pattern on a computer/laptop screen and you had a single photo transistor as your sensor. what amount of information could you represent such that you could still decode it when manually moving your sensor over the screen ? | 17:10 |
| wpwrak | the movement should be "natural" and convenient. so it shouldn't have to be repeated a lot, speed may be imprecise, and you also can't just expect the sensor to be stationary for a long time. | 17:11 |
| wpwrak | what i'm looking for the is cheapest and simplest possible method for getting data from a web site via a PC/laptop to a small external device. cheaper and simpler than USB. | 17:12 |
| mth | does the external device have a net connection of its own? | 17:16 |
| mth | I mean, do you need to pass only a reference to the data or the data itself? | 17:16 |
| wpwrak | no, doesn't connect to anything | 17:16 |
| wpwrak | for this to be useful, i need to transfer about 1-2 kB of data. maybe i can segment it into smaller pieces, but 1-2 kB would be ideal | 17:16 |
| mth | you could use a single location that changes intensity, you it would get 60 bits/second in the best case | 17:17 |
| wpwrak | too slow | 17:18 |
| mth | barcodes used on groceries contain a ~10 digit number, that's not a lot of bits either | 17:18 |
| mth | I guess you can scan one or two of those per second | 17:19 |
| wpwrak | (1-2 kB. before compression. compression should be able to reduce this by about 50%.) | 17:19 |
| mth | of course that is old tech, not sure how much you could get with more computation power | 17:19 |
| mth | and it has to be done via the screen? not something like NFC? | 17:20 |
| wpwrak | hmm, let's see how much information is there in the first place. the screen should be 1024xsomething or better. each pixel has, best case, 256 brightness values (let's assume monochrome). so that would be 1 kB of raw data. tight :) | 17:21 |
| wpwrak | it should work with any PC you're likely to encounter | 17:22 |
| mth | a lot of panels don't have 8 bits per pixel | 17:22 |
| wpwrak | yes. "best case" :) | 17:22 |
| wpwrak | maybe 4 real-life usable bits. | 17:22 |
| mth | error correction is going to add some overhead as well | 17:24 |
| mth | unless you have so few errors that a CRC is sufficient | 17:24 |
| mth | you could draw the barcode in some kind of spiral, that might give you more pixels | 17:25 |
| wpwrak | hmm, makes the movement inconvenient | 17:26 |
| mth | a square spiral might not be so bad | 17:26 |
| wpwrak | buy maybe a U shape or even a zig-zag may work | 17:26 |
| wpwrak | "Z" like "Zorro" ;-) | 17:27 |
| kristianpaul | Z :) | 17:55 |
| kristianpaul | or T | 17:56 |
| DocScrutinizer51 | wpwrak: in a minute | 18:19 |
| DocScrutinizer | wpwrak: that'S what the barcodes with always ame width white bars, plus black bars smaller and larger than the white ones are | 18:34 |
| DocScrutinizer | your clock "PLL" will sync on white, next black bar is either shorter or longer than the last white one | 18:34 |
| DocScrutinizer | even simpler though is playback of a flash movie or sth, that does fullscreen b&w "morse" | 18:37 |
| DocScrutinizer | I.E 50,8N1 | 18:38 |
| DocScrutinizer | 25? | 18:38 |
| DocScrutinizer | 10? | 18:38 |
| larsc | my onlinebanking does that kind of thing. if have devices which looks like it has 5 light sensors and data is transfered by holding it in front of a b/w morse kind of flash app | 18:56 |
| wpwrak | hmm. 5 channels. maximum 50 symbols/sec each. not sure how many bits you can encode in the color. let's say 4. that would be 1 kbit. not bad. but still slow. | 19:09 |
| larsc | how smart is the device on the other side? | 19:12 |
| wpwrak | AVR class | 19:13 |
| larsc | hm | 19:13 |
| wpwrak | not quite sure what MCU to take. just has to be cheap :) | 19:13 |
| larsc | one think that might allow you to use more brightness levels is to have each valid code word contain one element of min and one of max brightness | 19:16 |
| wpwrak | yes, sort of like bit stuffing. just a little more advanced. | 19:19 |
| larsc | turbo codes for ECC | 19:22 |
| wpwrak | a manual sweep of a static display would pass over ~800 pixels in ~1-2 seconds. much better data rate than an animation :) | 19:24 |
| larsc | but you need to move at const speed | 19:26 |
| wpwrak | hmm, not overly erratic speed. you can have some clock recovery in the pattern. | 19:29 |
| DocScrutinizer | see above comment of mine | 19:39 |
| DocScrutinizer | you'll want to use a minimum of 3 px stripes though, for each "bar" | 19:39 |
| DocScrutinizer | so incl clock (white) that's avg min of 7.5px/bit | 19:41 |
| DocScrutinizer | minus CRC | 19:41 |
| wpwrak | with grey levels, how many bits do you think i could have per bar ? | 19:42 |
| DocScrutinizer | hardly more than 2 | 21:02 |
| larsc | if you use turbo codes at least 4 | 21:04 |
| wpwrak | hmm, so 2 bits per 3 pixels. let's say in a 600 pixel zone (with places for start and landing), Z shape. so that's 600/3*2*3 bits. 1200 bits, 150 bytes. not much :-( | 21:04 |
| wpwrak | and that's without overhead | 21:04 |
| LunaVorax | Hey everyone! | 21:27 |
| LunaVorax | Hi wpwrak :) | 21:27 |
| qi-bot | [commit] Paul Cercueil: Reinitialize the powersaver timer when a suspend has been detected. (master) http://qi-hw.com/p/gmenu2x/2d81b13 | 22:37 |
| --- Fri Feb 3 2012 | 00:00 | |
Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!