| 00:00.00 | wpwrak | nice margin :) |
| 00:03.20 | wpwrak | spec like this ? https://privatepaste.com/336be8b3d3 |
| 00:04.30 | DocScrutinizer51 | web! meh |
| 00:04.46 | wpwrak | oh, sorry ;-) |
| 00:04.57 | DocScrutinizer51 | microB sucks, just a bit |
| 00:05.11 | wpwrak | is looking for a suitable gopher server ... |
| 00:05.16 | DocScrutinizer51 | 256MB ram |
| 00:05.22 | wpwrak | microB ? or AB ? |
| 00:05.43 | wpwrak | or maybe you're talking about something else :) |
| 00:05.56 | DocScrutinizer51 | N900 |
| 00:06.18 | DocScrutinizer51 | microB is N900 std webbrowser |
| 00:07.27 | DocScrutinizer51 | I could use opera, but whatever I do, the ram and swapping makes it a sucking experience |
| 00:09.18 | DocScrutinizer51 | fremantle is much better than android on that, but 256MB is just too little |
| 00:09.31 | DocScrutinizer51 | ~ping |
| 00:09.31 | infobot | ~pong |
| 00:10.12 | wpwrak | sigh, what happened to the good old days when we ran linux in 4 MB but had to upgrade to 8 MB if we wanted these fancy graphics, with X11 and all those luxuries ... |
| 00:10.13 | ShadowJK | (opening that link caused 0 swapping on my n900) |
| 00:11.51 | DocScrutinizer51 | ShadowJK: got lazy with the years |
| 00:12.20 | DocScrutinizer51 | and old ;-P |
| 00:12.23 | dos1 | lynx opened that wihout any problem! ;) |
| 00:12.32 | FIQ | what is shared/buffers/cache and why isn't it present in N900's free? |
| 00:12.35 | dos1 | + no swapping :D |
| 00:13.32 | ShadowJK | busybox free doesn't show it |
| 00:13.45 | FIQ | <PROTECTED> |
| 00:13.46 | FIQ | Mem: 513620 397844 115776 0 13840 222984 |
| 00:13.46 | FIQ | -/+ buffers/cache: 161020 352600 |
| 00:13.46 | FIQ | Swap: 128400 16696 111704 |
| 00:13.47 | ShadowJK | cat /proc/meminfo for (almost) everything |
| 00:13.52 | FIQ | ahh |
| 00:13.53 | FIQ | ok |
| 00:13.54 | DocScrutinizer51 | notices he has accidentally closed xtern 3 days ago |
| 00:14.04 | FIQ | DocScrutinizer05, nice |
| 00:14.12 | DocScrutinizer51 | fuck messybox! |
| 00:14.43 | FIQ | huh |
| 00:14.57 | FIQ | <PROTECTED> |
| 00:14.57 | FIQ | <PROTECTED> |
| 00:14.57 | FIQ | <PROTECTED> |
| 00:14.57 | FIQ | Total: 642020 414532 227488 |
| 00:15.05 | FIQ | output from "busybox free" |
| 00:15.14 | FIQ | it does show buffers :P |
| 00:15.18 | FIQ | maybe a newer version |
| 00:15.19 | DocScrutinizer51 | proper bash and unix tools FTW |
| 00:16.02 | FIQ | yeah, coreutils>busybox |
| 00:16.30 | DocScrutinizer51 | first 5 keys after opening xterm: |
| 00:16.31 | DocScrutinizer51 | b |
| 00:16.32 | DocScrutinizer51 | a |
| 00:16.33 | DocScrutinizer51 | s |
| 00:16.34 | DocScrutinizer51 | h |
| 00:16.41 | DocScrutinizer51 | enter |
| 00:17.01 | FIQ | :P |
| 00:17.16 | FIQ | I had bash by default for a while |
| 00:17.22 | FIQ | but it messed with some stuff |
| 00:17.32 | FIQ | like the installer for cssu |
| 00:17.48 | FIQ | so I just made it a habit to "bash(enter)" asap |
| 00:17.49 | wpwrak | so .. is it okay ? https://privatepaste.com/336be8b3d3 |
| 00:17.55 | DocScrutinizer51 | yeah, maemo depends on messybox bugs |
| 00:19.48 | DocScrutinizer51 | wpwrak: I can open the pasyebin but not check |
| 00:20.11 | DocScrutinizer51 | sounds kinda okish |
| 00:20.32 | wpwrak | perfect, thanks |
| 00:21.04 | wpwrak | for reference, the 47590-0001 looks like this: http://media.digikey.com/Photos/Molex/0475900001.JPG |
| 00:21.19 | DocScrutinizer51 | no way |
| 00:21.30 | FIQ | so I heard about a blocksheet of the neo900 pcb |
| 00:21.34 | FIQ | did I hear wrong? |
| 00:21.40 | wpwrak | there are also two nice long legs at the rear side, not visible in the picture |
| 00:21.41 | DocScrutinizer51 | 3.xN screen |
| 00:21.56 | wpwrak | 640x640 pixels :) |
| 00:22.14 | wpwrak | here's 200x200: media.digikey.com/Photos/Molex/0475900001_sml.jpg |
| 00:22.21 | DocScrutinizer51 | 800x480 |
| 00:22.45 | wpwrak | FIQ: we're working on it :) |
| 00:22.53 | FIQ | ahhhh |
| 00:22.56 | FIQ | cool |
| 00:23.33 | FIQ | DocScrutinizer05, how much money transferred so far? |
| 00:23.35 | DocScrutinizer51 | sorry, my xchat doesn't offer to open this as URL |
| 00:23.50 | DocScrutinizer51 | 26k |
| 00:23.53 | wpwrak | http://media.digikey.com/Photos/Molex/0475900001_sml.jpg ? |
| 00:23.54 | FIQ | mine does |
| 00:24.00 | FIQ | hexchat though |
| 00:24.38 | wpwrak | it's the damn chromium url copy bug. they cleverly decided to "trim" urls when you copy them, like they do when displaying them |
| 00:24.39 | DocScrutinizer51 | wpwrak: looks good |
| 00:24.54 | FIQ | I hate that |
| 00:24.59 | DocScrutinizer51 | and took 8 s to load and render |
| 00:25.10 | wpwrak | fixed in more recent versions of chromium, but ubuntu are taking their own sweet time to catch up |
| 00:25.27 | FIQ | DocScrutinizer05, what are you on, 56k? |
| 00:25.39 | wpwrak | 300 bps, acoustic-coupler ? :) |
| 00:25.55 | DocScrutinizer51 | nfc |
| 00:25.56 | FIQ | wpwrak, typical ubuntu |
| 00:26.07 | DocScrutinizer51 | seems 2.5G |
| 00:26.16 | FIQ | ahhhh |
| 00:26.30 | FIQ | so 56k wasn't too far off |
| 00:26.45 | DocScrutinizer51 | yep |
| 00:27.23 | DocScrutinizer51 | also 2nd beer, and duuuude it tates good |
| 00:27.29 | DocScrutinizer51 | tastes* |
| 00:27.43 | wpwrak | hehe ;-) |
| 00:27.53 | FIQ | wpwrak, what version is ubuntu on @chromium? |
| 00:28.42 | DocScrutinizer51 | luckily rhose greek are tolerant to geeks in their pub |
| 00:29.18 | wpwrak | FIQ: 34.0.1847.116 |
| 00:29.24 | FIQ | ah |
| 00:29.32 | FIQ | not too far behind |
| 00:29.59 | wpwrak | the bug is fixed in 35, i think. so i'm hoping every day for some security issue that forces an upgrade :) |
| 00:30.08 | FIQ | :P |
| 00:30.38 | wpwrak | now ... the LED situation ... |
| 00:32.39 | DocScrutinizer51 | LEDs are great |
| 00:33.33 | FIQ | the more, the merri(christmas)er |
| 00:34.00 | DocScrutinizer51 | ...and I anounced 3color kbd backlight |
| 00:34.43 | FIQ | wasn't kbd supposed to be full RGB? :D |
| 00:35.04 | DocScrutinizer51 | that'a it |
| 00:35.13 | wpwrak | wants RGBX ;-) |
| 00:35.23 | FIQ | X? |
| 00:35.27 | wpwrak | X-ray :) |
| 00:35.30 | DocScrutinizer51 | 7bucks BOM |
| 00:35.33 | FIQ | duh |
| 00:36.01 | FIQ | Doc |
| 00:36.08 | FIQ | how much money transferred so far? |
| 00:36.15 | FIQ | 200 devices re-achieved\ |
| 00:36.16 | FIQ | ? |
| 00:36.35 | wpwrak | wonders how many of the fancy gadget will survive the first shocking priced BOM :) |
| 00:36.39 | DocScrutinizer51 | see backscroll |
| 00:36.44 | DocScrutinizer51 | 26 |
| 00:36.55 | wpwrak | 26 kEUR |
| 00:37.19 | DocScrutinizer51 | some 130 |
| 00:37.23 | DocScrutinizer51 | devices |
| 00:37.25 | FIQ | ok |
| 00:37.37 | DocScrutinizer51 | I'm about to resign |
| 00:37.37 | FIQ | so min order still not fulfulled |
| 00:38.05 | wpwrak | from what ? |
| 00:38.31 | DocScrutinizer51 | we NEED 200 preorders |
| 00:38.55 | wpwrak | there's still an unknown and probably non-zero number of pending donations at GDC. alas, it seems that a lot of people haven't reacted yet. |
| 00:39.10 | FIQ | od you know how much has been refunded back? |
| 00:39.17 | FIQ | i.e. disappeared donations |
| 00:39.22 | FIQ | *do |
| 00:39.44 | DocScrutinizer51 | no |
| 00:40.02 | DocScrutinizer51 | a good question to ask to Nik |
| 00:41.28 | DocScrutinizer51 | we already seen 3 re-donations of refunds |
| 00:43.02 | DocScrutinizer51 | yesterday adozen+ transfers cane in |
| 00:43.24 | wpwrak | with what we have, we should have no problems making V2, even if there's some risk-buy involved. if there's a lot of risk-buy, we should make an announcement that the "donate EUR >= 100 and your device is secure" period is ending. but i think this can still wait, though not for very long. |
| 00:44.21 | wpwrak | one V2 is on its way, we can make a "last call", give people some time to react, then see if things look friendly |
| 00:45.02 | DocScrutinizer51 | :nod: |
| 00:45.10 | FIQ | how much things still needs to be done? |
| 00:46.13 | FIQ | hmmm |
| 00:46.52 | wpwrak | FIQ: well, the V2 specification needs to be finalized. this is what we're doing now. then schematics need to be updated for it. then reviewed. then layout. again, review. then pcb-making and assembly. in parallel, sourcing. |
| 00:47.33 | FIQ | ok |
| 00:47.42 | wpwrak | FIQ: V2 will basically be a functional board (we hope :) that doesn't have the CPU and things in its immediate vicinity (companion chip, memories, etc.) |
| 00:47.52 | DocScrutinizer51 | wpwrak: you should ahre a link to block diagram |
| 00:48.16 | wpwrak | instead, an external board (beagle or such) will provide the "brain" |
| 00:48.55 | wpwrak | this is done to permit the use of a simpler PCB that's not as expensive (and possibly slow to make) as a board than can host the CPU |
| 00:49.28 | wpwrak | with that we should be able to test almost all of the peripherals: switches, sensors, leds, radios, ... |
| 00:50.17 | DocScrutinizer51 | modem |
| 00:50.38 | wpwrak | depending on how this goes, we can then decide what to do next. maybe we'll need another similar board spin, to fix bugs. maybe we're confident and do the next one already with cpu et al. |
| 00:50.49 | wpwrak | modem \in radios :) |
| 00:51.02 | FIQ | hmm |
| 00:51.18 | FIQ | 1GB RAM? I thought neo900 would get 512MB |
| 00:51.19 | wpwrak | (test peripherals) also mechanical compatibility with the case, etc. bunch of things. |
| 00:51.31 | FIQ | guess I mis-understood earlier |
| 00:52.52 | DocScrutinizer51 | we found what we hope will be 1GB |
| 00:52.54 | wpwrak | DocScrutinizer51: (block diagram) yes, i think when we're doing with the v2 spec, i can publish the PDF. next i'll clean up the hover texts, which are a mess now (i use them like "post-it"s, with broken links and so on) |
| 00:53.07 | wpwrak | #s/doing/done/ |
| 00:53.20 | FIQ | s/#// |
| 00:53.46 | wpwrak | traffic reduction :) |
| 00:55.37 | DocScrutinizer51 | dang, burned half of N900s battery |
| 00:56.27 | wpwrak | also need to add the legend. that'll take some tweaking of the tools, which currently assume every box is some sort of subsystem. well, nothing major. |
| 00:58.02 | wpwrak | (IR LED) spec like this ? 2) IR LED and driver (just transistor(s) ?) are in. We don't really care what they are, they just "have to work" :) |
| 00:58.17 | wpwrak | wonders what reaction this will produce :) |
| 00:58.59 | DocScrutinizer51 | hehe |
| 00:59.03 | wpwrak | prolly either "yes, i have EXACTLY what we need" (90%), or "hey !" (10%) |
| 00:59.45 | wpwrak | do we want to say anything about connecting to UART.TX ? |
| 01:00.07 | DocScrutinizer51 | heading home |
| 01:00.34 | wpwrak | UART3.TX mayhaps. (for the IrDA) |
| 01:01.48 | wpwrak | CIR may actually be more interesting, since we're unidirectional anyway |
| 01:07.45 | wpwrak | fascinating. in CIR mode, TX is on CTS. why, TI, why ? |
| 01:10.14 | DocScrutinizer05 | huh? |
| 01:10.22 | DocScrutinizer05 | WUT? |
| 01:10.30 | DocScrutinizer05 | wtf? |
| 01:11.07 | wpwrak | SPRUGN4R pages 2881/2882 |
| 01:11.31 | DocScrutinizer05 | we might want to have a good few beers on a saturday afternoon to finalice IRdA and CIR and UART3 |
| 01:11.32 | wpwrak | well, i guess one can just wire-or them, and let software decide |
| 01:12.11 | DocScrutinizer05 | you know my GTA04 specs? |
| 01:12.24 | DocScrutinizer05 | *my* GTA04 |
| 01:12.58 | DocScrutinizer05 | a lot of the good stuff is already there ;-) |
| 01:13.14 | wpwrak | (beers) actually, i would suggest that you and nik each print their schematics and stuff, then meet to go over every part/subsystem in the block diagram, to make sure there's no misunderstanding |
| 01:13.32 | wpwrak | (gta04 specs) naw, don't remember them |
| 01:14.01 | wpwrak | and it's good if the good stuff is making it ;-) |
| 01:14.37 | DocScrutinizer05 | http://people.openmoko.org/joerg/unsorted/gta04.pdf |
| 01:17.14 | wpwrak | so ... shall i say anything about how to connect IR ? if yes, how much ? is hw-supported CIR (RC5 et al.) a use case ? |
| 01:18.06 | wpwrak | the only use case i personally may find relevant i see so far would be raw UART TX over IR. not sure how well this actually works, though. |
| 01:18.20 | DocScrutinizer05 | you should read that pdf ;-) |
| 01:18.40 | wpwrak | yes, there you also have a receiver. but we won't have that, will we ? |
| 01:18.53 | DocScrutinizer05 | we will |
| 01:19.25 | DocScrutinizer05 | we use IrDA module in parallel to high power CIR wavelength IR LED |
| 01:19.34 | wpwrak | so much for "do whatever" .... |
| 01:20.02 | DocScrutinizer05 | ? |
| 01:20.41 | wpwrak | it's a lot of specification that just popped up from nowhere :) |
| 01:21.06 | wpwrak | okay, so we'll have an IR transmitter (CIR) plus an IrDA transceiver |
| 01:21.16 | DocScrutinizer05 | Nik seems to have some dedicated idea about how IrDA works and how it's not working on OMAP. We need to listen |
| 01:21.24 | wpwrak | both not sharing the LED |
| 01:21.29 | wpwrak | ah, i see |
| 01:21.31 | DocScrutinizer05 | yes |
| 01:22.33 | DocScrutinizer05 | don't feel scard by the 14 pages, 50% is cruft |
| 01:22.41 | DocScrutinizer05 | scared* |
| 01:23.00 | wpwrak | i just looked at IR ;-) |
| 01:23.44 | wpwrak | so for IR, we pass the ball to Nik. with "want: IrDA, CIR. tell us what you think" |
| 01:24.07 | DocScrutinizer05 | anyway, it has *all* the weird ideas of which 90% are idiocy. But the working hypothesis for this GTA04 project (predating any GDC GTA04 project) been "nothing is too crazy" |
| 01:24.48 | DocScrutinizer05 | I have a pretty clear idea re IrDA/CIR |
| 01:24.49 | wpwrak | at openmoko, a very reasonable assumption :) |
| 01:26.56 | wpwrak | --More-- ? |
| 01:27.08 | DocScrutinizer05 | we exploit UART3 which is tagged "IrDA" on TI OMAP specs. We get a second powerful CIR LED in parallel since IrDA sucks big time for CIR. And we allow console that's on UART3 anyway to "morse" 19800baud photon beam during boot, via IrDA and CIR |
| 01:28.31 | wpwrak | so this needs ... IR LED + driver (transistor or such), an IrDA transceiver, and some logic to connect TX and CTS when in "naked UART" mode |
| 01:28.39 | DocScrutinizer05 | we may want a NAND gate or whatever to disable IR when not needed |
| 01:28.59 | DocScrutinizer05 | UART3 is also on hacker bus |
| 01:29.17 | DocScrutinizer05 | yup |
| 01:29.41 | wpwrak | i see a lot of 74xx1G gates :) |
| 01:29.48 | DocScrutinizer05 | 3 maybe |
| 01:29.54 | wpwrak | yeah, something like that |
| 01:32.44 | wpwrak | let's see what the issues are ... 1) sharing of RX, IrDA vs. HB. 2) injection of TX into CTS, for "naked UART". 3) CTS direction reversal (it's normally an input but becomes an output for CIR). 4) make sure HB activity doesn't cause IR activity on TX/CTS/RTS. |
| 01:33.21 | DocScrutinizer05 | well, HB only works when IrDA disabled |
| 01:33.35 | DocScrutinizer05 | 2) nobrainer |
| 01:33.51 | wpwrak | what if something is connected to HB ? will it have to be disconnected to use IR ? |
| 01:33.57 | DocScrutinizer05 | 3) we never use CTS as input |
| 01:34.21 | DocScrutinizer05 | 4) is a feature, no bug |
| 01:34.29 | wpwrak | UART uses CTS as input. so HB will only have TX/RX, not CTS/RTS ? |
| 01:34.58 | DocScrutinizer05 | sorry, I rather do this in eagle than verbatim in here |
| 01:35.08 | DocScrutinizer05 | it's dead simple |
| 01:35.27 | DocScrutinizer05 | and doesn't add either to BOM or to complexity |
| 01:36.12 | DocScrutinizer05 | we need 1 or 2 GPIO for enabling stuff. And we need a few gates |
| 01:36.20 | DocScrutinizer05 | a driver FET |
| 01:36.26 | DocScrutinizer05 | that's it basically |
| 01:36.35 | wpwrak | ah, and is there a large enough window for IR LED + IrDA ? |
| 01:36.52 | DocScrutinizer05 | I'm honestly not happy with describing such stuff verbally |
| 01:37.06 | DocScrutinizer05 | that's agood question |
| 01:37.25 | DocScrutinizer05 | we need to take care for window being large enough |
| 01:37.41 | DocScrutinizer05 | the window is... |
| 01:38.23 | DocScrutinizer05 | like 5x5mm |
| 01:39.02 | wpwrak | ah, and will CIR also have a receiver ? or none ? or will it use the IrDA transceiver ? |
| 01:39.06 | DocScrutinizer05 | *should* suffice if we're no squareheads |
| 01:39.17 | DocScrutinizer05 | uses IrDA |
| 01:39.27 | wpwrak | 5x5 mm is pretty large |
| 01:39.54 | DocScrutinizer05 | we don't support proper CIR RX, only for learning purposes, which means <5cm distance |
| 01:40.16 | wpwrak | yeah, doesn't have to be fancy |
| 01:40.25 | DocScrutinizer05 | on 5cm IrDA works just fine for CIR wavelength |
| 01:40.49 | DocScrutinizer05 | we're not building a TV ;-) |
| 01:41.19 | DocScrutinizer05 | when somebody needs remote control for Neo900: please use BT or WLAN |
| 01:41.32 | DocScrutinizer05 | CIR RX no! |
| 01:41.52 | wpwrak | wonders if anyone will actually go through the trouble of using this. i could never bother to teach any of the IR-capable critters i had in the heydays of IR to act as remotes ... |
| 01:42.28 | DocScrutinizer05 | meh, there are several users who adore pierogi(?) |
| 01:42.50 | DocScrutinizer05 | we got IrDA anyway |
| 01:43.12 | DocScrutinizer05 | we will (ab)use it for learning, no question |
| 01:43.46 | wpwrak | ok. HB has RX, TX, RTS, CTS ? |
| 01:43.51 | DocScrutinizer05 | so that's: IrDA module + CIR wavelength high power LED |
| 01:44.15 | DocScrutinizer05 | (HB) sth like that. plus a lot more of course |
| 01:44.53 | DocScrutinizer05 | seen my suggestion to run HB via uSD breakout board B2GB directly from UPPER? |
| 01:45.09 | DocScrutinizer05 | B2B* |
| 01:45.38 | DocScrutinizer05 | peels a banana |
| 01:46.09 | wpwrak | i may have heard of it. no opinion so far. the whole HB concept is a bit suspicious to me. i prefer UBB. no soldering in the device, just plug it in and be happy ;-) |
| 01:47.08 | DocScrutinizer05 | soldering in device????????????? |
| 01:47.12 | DocScrutinizer05 | NO WAY! |
| 01:47.33 | wpwrak | ah, so HB has a connector ? |
| 01:47.35 | DocScrutinizer05 | pogo pins are geek |
| 01:47.52 | DocScrutinizer05 | and *maybe* even a flex connector |
| 01:47.55 | wpwrak | hmm, okay. $$$ |
| 01:48.10 | DocScrutinizer05 | not our $$$ |
| 01:48.28 | wpwrak | i'll just stick with UBB. proven technology ;-) |
| 01:48.51 | DocScrutinizer05 | when the pogos sit on any extension board and contact to pads on uSD breakout PCB... |
| 01:50.21 | wpwrak | how do you ensure proper positioning of Neo900 and external board ? |
| 01:50.29 | DocScrutinizer05 | but we *might* have a second feature for hacking: flex we deliver, that connects to aperture under battery and runs around battery to "outside" and there we solder a MCU onto the flex, and a prottyping area |
| 01:51.18 | DocScrutinizer05 | (positioning) place your extension into battery cover exactly like shown in thisistheway.pdf |
| 01:52.05 | wpwrak | what provides the holding force ? |
| 01:52.11 | DocScrutinizer05 | btw Jolla has pogos ;-P |
| 01:52.25 | DocScrutinizer05 | hm? |
| 01:52.46 | DocScrutinizer05 | the battery cover is pretty tighly sitting there |
| 01:53.45 | DocScrutinizer05 | http://magboss.pl/pubs/uploads/0253138-battery-cover-nokia-n900-black-(original),50a4bb269610f.jpg |
| 01:55.24 | DocScrutinizer05 | of course there *might* be too little free space to add a PCB under that cover. But we got Mugen cover, and endsormeans' awesome moose stuff |
| 01:55.26 | wpwrak | ah, i see. but then the board has to be either completely internal or needs an FPC to connect to the outside ? or is there some gap for more DIY-friendly cables ? |
| 01:56.17 | DocScrutinizer05 | when you want to go from inside N(eo)900 to outside, you need to mill a slot somewhere |
| 01:56.43 | wpwrak | is uSD accessible from the outside ? |
| 01:56.46 | DocScrutinizer05 | we won't offer 2holes" |
| 01:56.51 | DocScrutinizer05 | no |
| 01:57.00 | wpwrak | damn ! :-( |
| 01:57.24 | DocScrutinizer05 | that's why battery lid has a magnet ;-P |
| 01:57.48 | DocScrutinizer05 | and the Hall is labeled "uSD insert" OWTTE |
| 01:58.13 | DocScrutinizer05 | you NEED a N900!!!! |
| 02:02.04 | *** join/#neo900 infobot (~infobot@rikers.org) |
| 02:02.04 | *** topic/#neo900 is http://neo900.org | conversations are logged to http://infobot.rikers.org/%23neo900/ | 2013-11-04 - the day our fundraiser reached its goal, 25k EUR | 2013-12-02 - 200 devices reached! | 12-14 50035EUR, 232 units | 01-17 60kEUR, 300 units | 02-28 333 units, 70k€ | 03-28 350 units, 400 donations, 73555€ | 0501 360 410 75k |
| 02:02.04 | *** mode/#neo900 [+v infobot] by ChanServ |
| 02:02.19 | DocScrutinizer05 | already back |
| 02:06.25 | *** join/#neo900 infobot (~infobot@rikers.org) |
| 02:06.25 | *** topic/#neo900 is http://neo900.org | conversations are logged to http://infobot.rikers.org/%23neo900/ | 2013-11-04 - the day our fundraiser reached its goal, 25k EUR | 2013-12-02 - 200 devices reached! | 12-14 50035EUR, 232 units | 01-17 60kEUR, 300 units | 02-28 333 units, 70k€ | 03-28 350 units, 400 donations, 73555€ | 0501 360 410 75k |
| 02:06.25 | *** mode/#neo900 [+v infobot] by ChanServ |
| 02:07.02 | DocScrutinizer05 | meh, we don't intergate breakout boards into device |
| 02:07.41 | wpwrak | you plug this into uSD (right side). attach ribbon cable or circuit as desired (left side) |
| 02:07.56 | DocScrutinizer05 | useless ballast |
| 02:08.10 | wpwrak | you should know it well from #qi-hardware :) |
| 02:08.38 | wpwrak | 0 ballast. all you need is an externally accessible uSD holder |
| 02:08.57 | DocScrutinizer05 | sure, you'll get that when eMMC becomes a 2nd uSD |
| 02:09.15 | DocScrutinizer05 | see above |
| 02:09.17 | wpwrak | perfect :) |
| 02:09.59 | DocScrutinizer05 | [2014-07-03 Thu 03:59:18] <DocScrutinizer05> slot-in |
| 02:11.14 | DocScrutinizer05 | I guess we can perfectly place such slot-in uSD on upper side of spacer frame |
| 02:11.31 | DocScrutinizer05 | no problems with fat USB plugs |
| 02:11.44 | DocScrutinizer05 | close kbd slider to swap uSD |
| 02:13.18 | DocScrutinizer05 | just wonders if the 8bit databus eMMC interface is compatible to UHS uSD |
| 02:14.01 | DocScrutinizer05 | IOW: can OMAP MMC2(?) drive UHS? |
| 02:14.24 | DocScrutinizer05 | ShadowJK: ^^^? |
| 02:15.14 | DocScrutinizer05 | I want a *FAST* "eMMC" |
| 02:15.30 | DocScrutinizer05 | no cheesy 12MB/s |
| 02:17.34 | DocScrutinizer05 | I won't swap eMMC for a uSD with 4bit-25MHz interface |
| 02:17.50 | wpwrak | hmm, if the "new" uSD is more external than the "old" uSD, perhaps the old should be MMC2 (N900: eMMC) and the new MMC1 (N900: uSD) ? |
| 02:18.14 | DocScrutinizer05 | that's an easy change :-) |
| 02:18.21 | wpwrak | indeed :) |
| 02:18.51 | DocScrutinizer05 | what's not so easy: investigate if OMAP3 MMC2 can dribe UHS |
| 02:18.56 | DocScrutinizer05 | drive* |
| 02:22.43 | DocScrutinizer05 | anyway... make your diagram available to community! we don't expect perfection, we want to watch progress ;-) |
| 02:23.54 | DocScrutinizer05 | a good plan (or diagram ;-D) today is better than a perfect one tomorrow |
| 02:24.39 | DocScrutinizer05 | or, since you're more a sw-guy: release early, release often! |
| 02:25.46 | DocScrutinizer05 | n8! |
| 02:25.49 | DocScrutinizer05 | o/ |
| 02:28.49 | wpwrak | they only mention UHS timing at two places. don't explicitly claim compatibility. |
| 02:30.05 | wpwrak | MMC1: up to 48 MHZ (OPP100), 4 bit. so that's more like SDHC. |
| 02:37.31 | wpwrak | MMC2/3: also up to 48 MHz (OPP100), 8 bit (seems that SD the DM3730 claims compatibility with only goes to 4 bits, MMC can do 8). seems that there's no DDR. |
| 02:38.45 | wpwrak | so that seems to be roughly SD/SDHC/SDXC "High Speed" or UHS-I SDR25. |
| 02:39.34 | DocScrutinizer05 | good enough |
| 02:39.53 | DocScrutinizer05 | we might want to friggin trst this, in protoV2 ;-) |
| 02:40.08 | DocScrutinizer05 | test, even |
| 02:40.59 | DocScrutinizer05 | seems I need to get that XXXXXX beagleboard schematics |
| 02:42.52 | DocScrutinizer05 | sure OMAP doesn't claim 8bit uSD compliance. I guess that didn't exist when the datasheet got published |
| 02:43.19 | DocScrutinizer05 | the questin is more like: can uSD UHS do SDR? |
| 02:44.08 | wpwrak | probably. since already SDHC has it. |
| 02:44.34 | DocScrutinizer05 | well, for sure it can do legacy 4bit uSD SDHC |
| 02:44.48 | DocScrutinizer05 | but can it do EIGHTBIT |
| 02:45.00 | DocScrutinizer05 | SDR |
| 02:45.03 | wpwrak | ah, no idea |
| 02:45.39 | DocScrutinizer05 | seems the interface on SoC cand do DDR |
| 02:45.48 | DocScrutinizer05 | not to ask for QDR |
| 02:46.03 | DocScrutinizer05 | cannot |
| 02:46.23 | wpwrak | i didn't see DDR mentioned in TI's docs, correct |
| 02:46.32 | wpwrak | maybe if you bit-bang really fast ;-) |
| 02:46.33 | DocScrutinizer05 | QDR no way |
| 02:46.41 | DocScrutinizer05 | BWAHAHA |
| 02:47.14 | DocScrutinizer05 | tbh I got NFC how QDR works |
| 02:47.38 | DocScrutinizer05 | DDR is on rising and falling edge of clock, iirc |
| 02:47.49 | wpwrak | well, i did VGA out on the lowly ben nanonote with UBB ... ;-) for 1024x768, i had to use the MMC controller, though. couldn't bitbang it that fast. |
| 02:48.49 | DocScrutinizer05 | ................................. dooooooot .... no connection ...................... dooooooooot ...................... |
| 02:48.53 | DocScrutinizer05 | n8 |
| 02:48.59 | wpwrak | QDR seems to be cheating anyway. see http://en.wikipedia.org/wiki/Quad_Data_Rate_SRAM |
| 02:50.24 | wpwrak | it's basically DDR, but with read/write path separated. so IFF you 1) want to read AND write at the same time, AND 2) both are on compatible locations, AND 3) you're bursting, THEN you can go up to 4x SDR speed |
| 02:50.46 | wpwrak | if you're just reading and writing, it's no faster than DDR. |
| 02:52.24 | wpwrak | UHS-II seems to do the same. plus a "bundling" mode where the bus (i.e., both sides) is unidirectional |
| 03:08.16 | DocScrutinizer51 | hmm, good enough to give it a closer look |
| 03:14.49 | DocScrutinizer51 | 2nd really fast uSD of virtually unlimited size, instead of 32GB eMMC, that would *really* be a salling point |
| 03:15.30 | DocScrutinizer51 | selling* |
| 03:17.55 | DocScrutinizer51 | I start to wonder if we actually might want a USB hub on internal USB. Seems attaching a USB uSD-UHS2 adapter shouldn't be too hard |
| 03:23.33 | wpwrak | there's a root hub inside the DM3730 |
| 03:23.54 | wpwrak | we have 1 x USB OTG and 2 x USB HS host |
| 03:24.30 | wpwrak | the root hub has 3 ports, but DM3730 doesn't bring out the 3rd one |
| 03:26.03 | wpwrak | i'd be wary of tossing a lot more weird stuff into the system, though. better keep it ... well, i'd say "simple", but it's already very complex. maybe "possible" ? :) |
| 03:27.09 | wpwrak | if we cram every chip we like into the device, it'll be a nightmare to layout, never fully work, and cost as much as a nice new car |
| 03:28.57 | wpwrak | also, if things go well, then this may open the opportunity to design other things in the future. with less historical burden and more design flexibility. then there will still be many opportunities for adding cool features. |
| 03:30.28 | wpwrak | DocScrutinizer51: (kbd LED) so you still want the MSL0201RGB, i guess ? |
| 03:34.24 | DocScrutinizer51 | why not? |
| 03:36.41 | wpwrak | common anode: http://projects.goldelico.com/p/neo900/issues/541/ |
| 03:36.41 | DocScrutinizer51 | iirc I checked that it's sourcable, not excatly much more expensive tahn white alternatives, small enough, and I found a controller that can handle the config with common electrode |
| 03:37.17 | wpwrak | if we'd want to use these leds, we need ... 3 x TCA6507 plus a boost converter |
| 03:37.43 | wpwrak | anything nicer than TCA6507 ? |
| 03:38.02 | DocScrutinizer51 | wut? |
| 03:38.15 | wpwrak | reloads the ticket ... |
| 03:38.38 | wpwrak | the latest status is either different LEDs or TCA6507 |
| 03:39.44 | DocScrutinizer05 | meh, I found a way better driver |
| 03:40.22 | wpwrak | hear hear ! :) |
| 03:40.31 | DocScrutinizer05 | it's somewhere in mail convo |
| 03:40.37 | wpwrak | @#$^% |
| 03:41.11 | DocScrutinizer05 | TI chip iirc |
| 03:41.25 | DocScrutinizer05 | sth like 9*LED |
| 03:41.41 | DocScrutinizer05 | no 'engines' but plain PWM |
| 03:44.05 | DocScrutinizer05 | http://www.ti.com/product/lp55281 |
| 03:46.09 | wpwrak | oh, looks nice ! |
| 03:47.01 | wpwrak | FEATURES: "Audio Synchronization for a Single Fun Light LED" gargh |
| 03:47.17 | DocScrutinizer05 | hahaha yeah |
| 03:49.39 | DocScrutinizer05 | 0.90bucks |
| 03:49.41 | wpwrak | nik will hate its BGAishness :) |
| 03:49.43 | DocScrutinizer05 | 4 RGB |
| 03:50.06 | DocScrutinizer05 | we can use DIL, and make it a siutcase |
| 03:52.01 | DocScrutinizer05 | would also allow for a proper 21" monitor instead this flimsy 3.9" thing ;-P Finally! |
| 03:52.42 | wpwrak | make it 42". and 3D, please. |
| 03:52.58 | DocScrutinizer05 | whatever makes you happy :-) |
| 03:53.46 | wpwrak | phables was yesterday, now comes phelevison ! |
| 03:54.20 | wpwrak | just imagine what battery capacity you could pack into this. enough to jumpstart your tesla :) |
| 03:55.07 | wpwrak | LP55281 like the LED test feature :) |
| 03:55.08 | DocScrutinizer05 | http://www.youtube.com/watch?v=27aVPqpnL7Y |
| 04:04.15 | DocScrutinizer05 | we will use one lp5532 and 2 lp55281, and we can have an additional 4 RGB for whatever signalling purposes. I want to place those left and right side of kbd, under a opaque kbd/spacer-frame |
| 04:05.01 | wpwrak | way too small that phone. and too thick, misses the zeitgeist |
| 04:05.17 | DocScrutinizer05 | or maybe have two of them shine away from device, at outside of spacer frame |
| 04:05.44 | DocScrutinizer05 | so you can see then even when slider closed |
| 04:05.48 | DocScrutinizer05 | them* |
| 04:06.42 | wpwrak | why not use a spare channel for the N900 RBG LED ? |
| 04:07.10 | wpwrak | ah, wrong polarity |
| 04:07.17 | DocScrutinizer05 | because that LED has wrong config for lp55281 |
| 04:07.33 | DocScrutinizer05 | and lp55281 has no engines, for patterns |
| 04:08.30 | DocScrutinizer05 | otherwise we could've used the 6 channels of lp5521 and a single lp55281 |
| 04:08.41 | DocScrutinizer05 | for the 6 RGB on kbd |
| 04:09.46 | DocScrutinizer51 | and we want to keep lp5523m for fremantle |
| 04:10.14 | DocScrutinizer51 | s/5521/5523/ |
| 04:30.57 | DocScrutinizer05 | s/5532/5523/ |
| 04:34.08 | DocScrutinizer05 | http://wiki.maemo.org/N900_Hardware_LED http://wiki.maemo.org/LED_patterns#Lysti_Format_Engine_Patterns_and_Commands |
| 04:34.27 | DocScrutinizer05 | LP5523 can even calculate primes |
| 04:35.54 | DocScrutinizer05 | the engines are almost turing complete |
| 04:44.08 | DocScrutinizer05 | for driving kbd backlight the lp5523 is kinda overkill. For sure reserving engine3 for a silly braindead 100ms fade-in/out is absolute overkill |
| 04:44.42 | DocScrutinizer05 | (kbd backlight fade-in/out) |
| 04:45.34 | DocScrutinizer05 | also the kernel driver supports ony 50%(+1) of the 96 steps storage in LP5523 |
| 04:46.01 | DocScrutinizer05 | in a bored hour I will write a patch for this lp5523.ko |
| 04:53.56 | DocScrutinizer05 | bzw the lp5523.ko is an excellent example of the "problem2 with nokia's drivers. They all are quite fine, but not "universal", i.e. they stop when they implemented what Nokia needed for that particular pupose. 96 program steps, vars? forget it, wasted manpower |
| 04:54.21 | DocScrutinizer05 | same for lis302: the filter config is hardcoded |
| 04:55.36 | DocScrutinizer05 | obviously such code shouldn't go upstream |
| 05:04.17 | wpwrak | hmm, TPS22963 (modem power switch) availability doesn't look too hot. why not use the TPS22964 ? it's basically the same but has a "quick discharge" feature. so the modem would be actively drained. |
| 05:05.01 | wpwrak | (hardcoded filter) bwahaha :) |
| 05:16.02 | DocScrutinizer51 | we won't use such modem power switch |
| 05:17.33 | DocScrutinizer51 | useless cruft, not compliant with our security paradigm |
| 05:24.24 | wpwrak | so only a current monitor, no way to cut power ? |
| 05:25.34 | DocScrutinizer05 | why cut power twice? |
| 05:25.44 | DocScrutinizer05 | there's a swich inside modem to cut power |
| 05:25.53 | DocScrutinizer05 | switch* |
| 05:25.57 | wpwrak | yes, but we don't trust this one, do we ? |
| 05:26.10 | DocScrutinizer05 | that's why we monitor it |
| 05:26.25 | DocScrutinizer05 | I don't trust an external switch either |
| 05:26.38 | wpwrak | so again, only reactive. hmm. deleting the switch ... |
| 05:27.05 | wpwrak | well, the external switch has little risk of getting compromised firmware :) |
| 05:27.28 | DocScrutinizer05 | but it can fail as well, and *then* you're really in trouble |
| 05:27.59 | DocScrutinizer05 | plus it adds ESR which is strictly forbidden for modem |
| 05:29.02 | DocScrutinizer05 | we got an emergency-off line on modem, which should be good enough to kill modem instantly |
| 05:29.52 | DocScrutinizer05 | for the rest we got our security concept which is not locking down but monitoring |
| 05:30.12 | wpwrak | (ESR) so does the fuel gauge. 20 mOhm in GTA04b7v2wip |
| 05:30.25 | DocScrutinizer05 | I know |
| 05:30.37 | *** join/#neo900 jormungandr (~henry@213.23.120.114) |
| 05:30.58 | DocScrutinizer05 | so what? |
| 05:31.29 | DocScrutinizer05 | since gauge does it, we can repeat it another few times? Or remove gauge? |
| 05:31.47 | wpwrak | (emergency-off) should be interesting to see what happens when you receive a "silent SMS" and then try to emergency shut down |
| 05:32.18 | wpwrak | (gauge) naw, but "strictly forbidden" would mean "no exceptions". but we do make an exception there. |
| 05:32.25 | DocScrutinizer05 | when you receive a silent SMS, you're ooked in to network |
| 05:32.56 | DocScrutinizer05 | booked* |
| 05:33.48 | DocScrutinizer05 | I don't see the fool who keeps booked into network but is afraid to find his modem transmit |
| 05:33.50 | wpwrak | hmm, aren't there some devilries that also happen when the modem/phone is supposed to be "off" ? |
| 05:34.14 | DocScrutinizer05 | there's no "off" on Neo900 |
| 05:34.22 | DocScrutinizer05 | off means off means OFF |
| 05:34.45 | DocScrutinizer05 | hat's what we do monitoring for |
| 05:34.50 | DocScrutinizer05 | that's* |
| 05:35.55 | wpwrak | i mean in general. what i wonder is whether the module will honor an "emergency shutdown" if doing something nasty. |
| 05:39.07 | DocScrutinizer51 | something nasty would be hard power shutdown while e.g. last booked in cell id gets written to SIM. Can kill your SIM |
| 05:41.18 | DocScrutinizer51 | in case moden does something roge, you're supposed to immediately remove battery anyway, and either do proper forensics later or nuke the device with an axe right away |
| 05:42.25 | DocScrutinizer51 | you won't recover from "something rogue" by powercycling the mosem |
| 05:42.43 | DocScrutinizer51 | modem* |
| 05:44.18 | DocScrutinizer51 | how would you know you're just receiving a silent SMS? You only can tell _after_ you received it |
| 05:44.28 | wpwrak | not by cycling, but by having it firmly powered down before it can even try something |
| 05:44.53 | DocScrutinizer51 | for that we do monitoring |
| 05:45.17 | DocScrutinizer51 | (ftwdm) |
| 05:45.36 | wpwrak | monitoring = burglar alarm. power switch (or something conceptually equivalent) = a solid locked door. |
| 05:45.44 | wpwrak | both have their role |
| 05:45.56 | DocScrutinizer51 | nonsense |
| 05:46.16 | DocScrutinizer51 | we shut down modem by modem switch |
| 05:46.29 | DocScrutinizer51 | off = off |
| 05:46.34 | DocScrutinizer51 | ftwdm |
| 05:46.44 | wpwrak | ftwdm = ? |
| 05:47.11 | wpwrak | the modem switch is like a "do not enter" sign |
| 05:47.12 | DocScrutinizer51 | for that we do monitoring |
| 05:47.15 | DocScrutinizer51 | (ftwdm) |
| 05:47.17 | wpwrak | ah :) |
| 05:47.41 | DocScrutinizer51 | no |
| 05:47.45 | DocScrutinizer51 | off = off |
| 05:48.27 | DocScrutinizer51 | we're not doing that double lock you suggest |
| 05:48.29 | wpwrak | very german :) if it's forbidden, nobody will dare to do it ;-) |
| 05:48.41 | DocScrutinizer51 | eh? |
| 05:49.23 | DocScrutinizer51 | you invented the perpetuum mobile? |
| 05:49.36 | DocScrutinizer51 | off = off |
| 05:49.42 | DocScrutinizer51 | ftwdm |
| 05:50.15 | wpwrak | i'm just telling you which parts of the design will get attacked when marketing this as a "secure" device |
| 05:50.31 | DocScrutinizer51 | pfff |
| 05:51.10 | DocScrutinizer51 | sorry, been there ten times with *you* already |
| 05:51.31 | DocScrutinizer51 | a bazillion times with others |
| 05:51.35 | DocScrutinizer51 | boring |
| 05:51.44 | DocScrutinizer51 | no mood for sparring |
| 05:52.34 | DocScrutinizer51 | a subsystem that's OFF can't wake up out of thin air |
| 05:52.52 | DocScrutinizer51 | it can do nuttin |
| 05:53.28 | DocScrutinizer51 | and to make sure it's really off ftwdm |
| 05:56.04 | DocScrutinizer51 | when sth is really german then that's "let's place a second switch there, in cae switch#1 magically activates" |
| 05:56.26 | wpwrak | that's the alarm you get when it has done something you didn't expect. now you have to decide whether this was a false alarm or not, with the information you have at hand. and then, if you assume the alarm was for real, you need to evaluate the consequences and possible defensive actions. |
| 05:57.02 | DocScrutinizer51 | orly? |
| 06:01.20 | DocScrutinizer51 | we will *know* when moden isn't off, o magically activates when it shouldnt |
| 06:02.25 | DocScrutinizer51 | when you *receive* sth, you obviouslz already accepted modem powering up and sending to log in |
| 06:03.06 | DocScrutinizer51 | when you still didn't remove your battery, then your fault |
| 06:03.52 | wpwrak | the modem is probably much faster than the user ... |
| 06:05.29 | DocScrutinizer51 | first alarm yelled when modem powered up. Second when TX AMP activates for auth some 10s later, 3rd when RF gers detected. Sorry the latter is actually 6th or 7th |
| 06:06.03 | DocScrutinizer51 | and on each we assert emergency power-off |
| 06:07.33 | DocScrutinizer51 | and actually a sileny SMS is completely unnecessary after you TXed anyway shortly before |
| 06:08.25 | DocScrutinizer51 | we're not blocking rogue activity, we notice it and act accordingly |
| 06:09.04 | DocScrutinizer51 | with a detour, a friend, a fake conversation, an axe |
| 06:10.05 | wpwrak | yes, that can be worked into a good story (in the sense of use case) |
| 06:10.12 | DocScrutinizer51 | and still, off is off is OFF |
| 06:11.04 | DocScrutinizer51 | a powered down modem cannot do "rogue stuff" |
| 06:11.26 | DocScrutinizer51 | no matter which switch powered it down |
| 06:11.28 | wpwrak | it's not ;-) but we can try to draw attention from this detail. because "off" also carries information. so sometimes it's indeed beneficial to just let the bad things happen, without trying to stop them. |
| 06:12.13 | DocScrutinizer51 | sorry, you speek in ridles |
| 06:12.57 | DocScrutinizer51 | I'm tired of this discussion |
| 06:13.16 | wpwrak | someone who tracks you may be interested when you turn off your modem. because that's when you may be trying to hide something. |
| 06:15.25 | wpwrak | it's still difficult to define proper countermeasures, though |
| 06:19.26 | DocScrutinizer51 | this morning that's your problem now. I can tell you that a second switch is not the solution to it |
| 06:20.34 | wpwrak | i guess we can agree to disagree ? |
| 06:22.54 | DocScrutinizer05 | no way |
| 06:23.53 | wpwrak | do you know what the expression means ? |
| 06:28.11 | DocScrutinizer51 | you know that an electronic device that's off can't get active out of itself? |
| 06:29.28 | DocScrutinizer51 | I won't accept any different claims |
| 06:30.12 | DocScrutinizer51 | you had to explain how that could ahppen, or there's zilch to disagree |
| 06:31.23 | wpwrak | how do you turn the modem "off" ? |
| 06:31.30 | DocScrutinizer51 | a powered down modem cannot receive *anything* (anything less than an EMP anyway) |
| 06:31.53 | DocScrutinizer51 | the question is meaningless |
| 06:32.06 | DocScrutinizer51 | ask how I know it IS off |
| 06:32.15 | DocScrutinizer51 | ftwdm |
| 06:33.57 | wpwrak | alright, so you have the alarm bells ringing in your pocket. by the time you have the phone out, it has done whatever it did. you're assuming it's fine if the modem does whatever it wants. but that may not be the case. |
| 06:34.11 | DocScrutinizer51 | thus there is no "off" on Neo900, off is off is OFF, but i guess I repeat myself |
| 06:34.32 | wpwrak | the modem can power itself on anytime it likes |
| 06:34.34 | DocScrutinizer51 | nonsense! |
| 06:34.54 | DocScrutinizer51 | NONSENSE!!! |
| 06:35.06 | wpwrak | i'm curious about this statement |
| 06:35.17 | wpwrak | why can't the modem power itself on ? |
| 06:35.37 | DocScrutinizer51 | I hate repeating me repating me repating me |
| 06:35.50 | wpwrak | or do you define "off" = "all power sources have been removed" ? |
| 06:36.49 | DocScrutinizer51 | meh! I honestly wonder if you do that on purpose. I planned to get up this time, now I hope eventually I gonna sleep |
| 06:37.17 | DocScrutinizer51 | also your problem as well |
| 06:37.35 | DocScrutinizer51 | when I don't reach anybody during daytime |
| 06:39.24 | DocScrutinizer51 | I really don't get it how you can state stuff like 'a szstem that evidently doesn't consume any energy can suddenly deliberately change state" |
| 06:40.39 | DocScrutinizer51 | and btw a modem needs at *least* 10s after power up to even find a cell to register to |
| 06:42.17 | wpwrak | i didn't state this. but i don't think the modem every powers down completely. there ought to be some standby circuit, RTC, or whatever. and an RTC can wake up the rest. and yes, this takes a bit of time. |
| 06:42.43 | wpwrak | anyway, you said you wanted to get some rest. i'll do the same soon :) |
| 06:43.19 | DocScrutinizer51 | your magic modem does: power up from complete inactivity (prolly based on radioactive decay), then ignore emergency-off, then book into network in no time (sth that would make you rich when you tell Siemens how to do that) and again ignore emerg-off, then start rogue activity, and again ignore... |
| 06:45.10 | wpwrak | PLS8-E_HD_v01.000, page 53, Ibatt, "OFF State supply current", "POWER DOWN", typical rating 40 uA. now tell me this is "evidently doesn't consume any energy" |
| 06:45.30 | wpwrak | i really don't understand what you're trying to argue here. |
| 06:45.45 | DocScrutinizer51 | I damn sure would rather want to know modem did all tose amgic things, tahn simply try to block them |
| 06:46.46 | wpwrak | yes, that's a valid point. if you want to research the behaviour of a compromised modem, you would indeed be interested in such experiments. |
| 06:47.25 | chainsawbike | why not allow users the choice? having a power switch for the modem gives *them* the choice to power down or just monitor |
| 06:48.41 | DocScrutinizer51 | know aht? simly remove your battery! |
| 06:49.58 | chainsawbike | tbh i would like to use it while in remote locations ( to take photos and stuff ) - there is no cellphone reception there, fully powering down the modem will give me slightly more battery life |
| 06:51.13 | chainsawbike | i want my device on, but have no need for modem |
| 06:51.21 | DocScrutinizer51 | headdesks |
| 06:51.57 | DocScrutinizer51 | THE MODEM IS OOOOOFFFFFF |
| 06:52.51 | chainsawbike | <wpwrak> PLS8-E_HD_v01.000, page 53, Ibatt, "OFF State supply current", "POWER DOWN", typical rating 40 uA. |
| 06:53.07 | chainsawbike | maybe, but its using power |
| 06:53.58 | DocScrutinizer51 | no |
| 06:54.26 | DocScrutinizer51 | you obviously have no clue what's a uA |
| 06:54.35 | chainsawbike | peanuts |
| 06:55.37 | chainsawbike | its effectively nothing, but it is still something |
| 06:56.17 | DocScrutinizer05 | yeah, and the switch wpwrak suggests need 100uA even on open state |
| 06:56.21 | DocScrutinizer05 | ;-P |
| 06:56.26 | DocScrutinizer05 | or 200 |
| 06:56.41 | chainsawbike | then there is a problem :) |
| 06:56.44 | DocScrutinizer05 | and probably 500 when closed |
| 06:57.18 | DocScrutinizer05 | honestly, I feel quite bored by this discussion now |
| 07:00.19 | wpwrak | close :) 760 nA with Von = 0 ("shut down"), 38 uA when closed. the latter is indeed a little high for my taste. |
| 07:02.17 | chainsawbike | DocScrutinizer05, is you disliking to a "power switch" just power usage or something else? |
| 07:03.14 | DocScrutinizer05 | [2014-07-03 Thu 07:39:07] <DocScrutinizer51> something nasty would be hard power shutdown while e.g. last booked in cell id gets written to SIM. Can kill your SIM |
| 07:03.55 | DocScrutinizer05 | [2014-07-03 Thu 07:27:59] <DocScrutinizer05> plus it adds ESR which is strictly forbidden for modem |
| 07:04.23 | DocScrutinizer05 | plus it's cruft |
| 07:04.46 | *** join/#neo900 Kabouik (~quassel@147.99.218.243) |
| 07:08.10 | DocScrutinizer05 | http://privatepaste.com/e1b3c79042 when this fails, there's something TERRIBLY wrong (and you would want to know) |
| 07:08.56 | DocScrutinizer05 | actually I'd think this cannot fail, since omplemented in hw, but anyway we would know when it would fail |
| 07:09.33 | *** join/#neo900 thrakcattack (~u@62-46-238-225.adsl.highway.telekom.at) |
| 07:10.59 | DocScrutinizer05 | when modem would wake up out of nothing (which is is NOT supposed to do) then we would also know immediately, and try ^^^. So this would already be two things that had to fail or work in a completely unexpected way for something remotely "dangerous" to happen... And STILL we would KNOW immediately |
| 07:11.11 | wpwrak | sounds as if EMERG_OFF would also undo switching from USB to (possibly absent) UART. any thoughts on that, dos1 ? |
| 07:21.11 | DocScrutinizer05 | such settings are sticky even across (real) power removal |
| 07:23.06 | DocScrutinizer05 | dos1 already answered same wording, he observed similar settings survive battery removal |
| 07:23.15 | DocScrutinizer05 | and TRM sais same |
| 07:23.19 | DocScrutinizer05 | says |
| 07:23.58 | DocScrutinizer05 | seems they have some flash area to store such settings |
| 07:24.27 | DocScrutinizer05 | they evidently have for other stuff, like manufaturer ident string on ATIn |
| 07:25.22 | DocScrutinizer05 | PH8_an43_customizing_v01 |
| 07:25.50 | DocScrutinizer05 | 2.2.1 Example: Using AT^SCFG to Customize USB Descriptors |
| 07:27.52 | DocScrutinizer05 | http://wstaw.org/m/2014/07/03/plasma-desktopKQ1814.png |
| 07:33.49 | DocScrutinizer05 | http://wstaw.org/m/2014/07/03/plasma-desktopuc1814.png |
| 07:34.11 | DocScrutinizer05 | http://wstaw.org/m/2014/07/03/plasma-desktopmQ1814.png |
| 09:34.36 | dos1 | EMERG_OFF doesn't work on my proto, so I can't test it, but AT^SDPORT for sure persists across reboots |
| 09:34.54 | dos1 | either clean ones or by brutal battery take off :P |
| 09:39.26 | *** join/#neo900 thrakcattack (~u@62-46-238-225.adsl.highway.telekom.at) |
| 09:44.57 | *** join/#neo900 Kabouik_ (~quassel@147.99.218.243) |
| 10:59.13 | *** join/#neo900 menesas (~newsbeute@ctv-95-173-42-187.vinita.lt) |
| 11:21.22 | DocScrutinizer05 | anyway, we can have that switch in protoV2 for sure. No problem with me, just I honstly wonder why we would need it (and the expense in PCB real estate and BOM) for the series device |
| 11:59.37 | *** join/#neo900 thrakcattack (~u@62-46-238-225.adsl.highway.telekom.at) |
| 12:25.08 | *** join/#neo900 Wizzup (~Wizzup@2001:981:a731:1:f2ad:4eff:fe00:f3d) |
| 13:24.33 | wpwrak | (universal break-out board) a glorious morning - qi-hw servers are up again :) this is what UBB is about: http://en.qi-hardware.com/wiki/UBB |
| 13:25.32 | wpwrak | some example uses, or developments of the concept: http://en.qi-hardware.com/wiki/UBB#Current_Outcomes |
| 13:27.21 | wpwrak | (i think UBB was priced a bit too high, so very few people bought it, and those who did often got only small quantities. such a thing should be perceived as "cheap", so you consume one per project/experiment without feeling guilty. making such small pieces of PCB is certainly inexpensive enough.) |
| 13:27.42 | wpwrak | dos1: seems they built their trap well ;-) |
| 13:29.19 | wpwrak | (EMERG_OFF) would be interesting to know how it's implemented. it sounds as if it could be simply an MCU reset. but maybe there's more to it, e.g., if some things require "clean" completion. like the SIM writes DocScrutinizer05 mentioned. |
| 13:31.46 | wpwrak | in this case, if cinterion felt confident enough, it could be an NMI or even a regular maskable interrupt. it should be possible to determine what is the most likely implementation by observing the modules' behavior (voltages at certain pins, current consumption, etc.) with an oscilloscope, in response to EMERG_OFF in various operating states. |
| 13:36.08 | wpwrak | (SIM corruption if powering down at the wrong time) that's a good point. use of the switch (if equipped) would have to follow a certain protocol. e.g., 1) issue AT+CFUN=0 and do any related power-down rituals (suspend PHY, etc.), 2) lock modem access (by host software, so that nothing accidently switches the modem back on), 3) wait x.xxx seconds, 4) cut power with switch, 5) unlock modem access. |
| 13:37.31 | wpwrak | the tricky bit is determining the correct grace period (the x.xxx seconds), but we need to do this anyway for the monitoring profile |
| 13:37.50 | dos1 | "grace periods" are specified in docs |
| 13:38.14 | wpwrak | oh, excellent. as "typical" or "maximum" values ? |
| 13:39.07 | dos1 | as maximum, aka "wait X secs after doing that" |
| 13:39.43 | wpwrak | perfect :) |
| 14:08.03 | *** join/#neo900 thrakcattack (~u@62-46-238-225.adsl.highway.telekom.at) |
| 14:52.19 | *** part/#neo900 freemangordon (~ivo@46.249.74.23) |
| 14:53.12 | *** join/#neo900 freemangordon (~ivo@46.249.74.23) |
| 15:11.09 | DocScrutinizer05 | we also have monitoring, so we don't need to guess how long it takes to shut down the modem |
| 15:38.54 | wpwrak | well, it's good to have the manufacturer's values as a basis. e.g., there may be cases where it takes a lot longer for some reason, but these cases don't occur in your network (or they occur only rarely, so you're not likely to see them very often) |
| 15:39.50 | wpwrak | err, does anyone know the I2C address of the front camera ? seems that it might be 0x10 or 0x37 ? (smiapp, default/alt) |
| 16:56.54 | freemangordon | wpwrak: just a second |
| 17:01.13 | freemangordon | wpwrak: #define SMIA_SENSOR_I2C_ADDR(0x20 >> 1) |
| 17:02.05 | wpwrak | thanks ! |
| 17:04.10 | DocScrutinizer05 | doesn't sound like FRONTcamera |
| 17:04.25 | DocScrutinizer05 | SMIA sounds like main aka rear camera |
| 17:05.11 | freemangordon | rear camera is et8ek8 afaik |
| 17:05.53 | DocScrutinizer05 | (cases) when the driver uses monitor to determine when subsystem has shut down, there's no need to have any hardcoded dealy value |
| 17:06.04 | DocScrutinizer05 | freemangordon: correct |
| 17:19.17 | wpwrak | oh, damn. you're right |
| 17:19.34 | wpwrak | lemme check where this came from ... |
| 17:24.38 | wpwrak | this is the source: https://www.mail-archive.com/linux-media@vger.kernel.org/msg75465.html |
| 17:25.22 | wpwrak | so i have the wrong module number ? |
| 17:25.28 | wpwrak | what is the front camera then ? |
| 17:33.38 | freemangordon | wpwrak: frontcam == smiapp, rearcam(maincam) == et8ek8 |
| 17:34.24 | freemangordon | #define ET8EK8_I2C_ADDR(0x7C >> 1) |
| 17:34.26 | freemangordon | #define SMIA_SENSOR_I2C_ADDR(0x20 >> 1) |
| 17:41.35 | wpwrak | ah, thanks a lot ! |
| 17:43.53 | wpwrak | we may use the N97 camera instead of the N900 camera. does anyone know the I2C address of that one, too ? |
| 17:47.43 | wpwrak | err, quick check on the remaining issues: 1) flash driver & LED: still TBD - we want them in V2, right ? 2) analog switch for BOOT_MODE. we won't have BOOT_MODE but do we want the switch in V2 ? or later ? |
| 17:48.08 | wpwrak | 3) should V2 mention/include the hackerbus ? or is this for later ? |
| 17:48.41 | DocScrutinizer05 | I2C addr of N97 cam is a funny and good question. I'd _hope_ it has same addr though |
| 17:49.25 | DocScrutinizer05 | 1) right, and TBD indeed |
| 17:49.55 | DocScrutinizer05 | 2) no need for any switch, we have no CPU on protoV2 |
| 17:50.17 | wpwrak | 1) in V2 ? post-V2 ? undecided ? just wanna make sure it gets the right classification |
| 17:50.27 | DocScrutinizer05 | what we however want is a test LED showing the state of the relevant chargerchip outputs |
| 17:50.49 | DocScrutinizer05 | we want them in V2, right ? -- right |
| 17:50.56 | wpwrak | in addition to the RGB LED ? |
| 17:51.14 | wpwrak | (test LED, i mean) |
| 17:51.20 | DocScrutinizer05 | we need _one_ LED, however that works on V2 level |
| 17:52.04 | DocScrutinizer05 | when we already got comprehensive coverage of all status outputs via normal LED handling, then that's also fine |
| 17:52.41 | DocScrutinizer05 | but meybe we don't want to integrate that double function of indicator_LED into V2 yet |
| 17:52.54 | DocScrutinizer05 | to have clean separate testing subsystems |
| 17:53.38 | wpwrak | seems pretty low-risk. also, you'd test these things separately anyway |
| 17:53.58 | DocScrutinizer05 | generally think of "dead simple driver + LED" as a function block sprread arbitrarily across whole proto design wherever needed |
| 17:54.36 | DocScrutinizer05 | we will have a dozen of those |
| 17:55.48 | DocScrutinizer05 | we will also want at least 4..5 different colors for those LED |
| 17:56.17 | DocScrutinizer05 | and never use same color for two LED close to each other |
| 17:57.10 | wpwrak | so that's a new set of requirements for V2. maybe you can make a list on which signals you want LEDs, which color, and whether they should turn on on L or on H ? |
| 17:57.48 | wpwrak | i just hope nik doesn't plan to hand-solder the board ;) |
| 17:58.44 | DocScrutinizer05 | wpwrak: nope. such a list is not needed. Such LEDs are placed ad-hoc when you sense a pin on a chip you just integrate which could need one |
| 17:59.23 | wpwrak | so who decides that ? |
| 17:59.30 | DocScrutinizer05 | me, in the end |
| 18:00.22 | DocScrutinizer05 | please don't tell me we need to specify 12 LEDs plus 12 transistors to get a proper quote |
| 18:00.25 | wpwrak | so the plan is that 1) we finish the spec, based on the block diagram. 2) nik draws the schematics based on this. 3) you review the schems and specify the "debug LEDs". 4) nik does layout etc. |
| 18:00.42 | wpwrak | no, i just want to make sure we all agree on the workflow |
| 18:01.03 | DocScrutinizer05 | basocally yes, though there will probably be 2 or 3 such iterations of me reviewing schem |
| 18:01.30 | wpwrak | ok, workflow gets a little loop :) |
| 18:01.40 | DocScrutinizer05 | initial specifications are just for estimating complexity |
| 18:01.51 | wpwrak | ok |
| 18:02.52 | DocScrutinizer05 | when we wpould speify everything down to last resistor, we could already do the schematics instead, and the ask eagle to autoroute it |
| 18:03.06 | DocScrutinizer05 | would specify* |
| 18:04.10 | DocScrutinizer05 | that's why I said "Mehrungen werden angekuendigt und dann uebernommen" |
| 18:05.09 | DocScrutinizer05 | I don't expect Nik to offer someting on an unclear spec and then me to rush over it and specify twice the number of components |
| 18:05.37 | wpwrak | next issue (last one for today), 3) should V2 mention/include the hackerbus ? or is this for later ? |
| 18:05.39 | DocScrutinizer05 | when I do additional specs, Nik will provide an informal mini-quote on those mods |
| 18:06.27 | DocScrutinizer05 | when I ask for 10 LEDs and 10 transistors, I hope he won't charge us much for such change |
| 18:07.16 | DocScrutinizer05 | (HB) undecided yet. We need to discuss this. Probably not much of HB in V2 yet |
| 18:07.19 | wpwrak | it's not just about the quote but to have an idea of what to expect in general. it can be a bit frustrating when you think you're as good as done, and then suddenly two dozen LEDs spring up. particularly if you already thought about the layout at that point. |
| 18:07.29 | wpwrak | (HB) perfect ;-) |
| 18:08.41 | DocScrutinizer05 | (layout) that's why a frequent sharing of schematics interim results from Nik to me is mandatory, so any changes and comments can get in early |
| 18:09.26 | DocScrutinizer05 | it's not like we order a V2 at GDC and 6 weeks later GDC delivers the ready PCB incl docs and project files |
| 18:09.42 | DocScrutinizer05 | this is subcontractor work in close cooperation |
| 18:10.16 | DocScrutinizer05 | we _cannot_ specify V2 (or Neo900) as finegrained as that |
| 18:10.59 | DocScrutinizer05 | during R&D there will _always_ be changes |
| 18:11.30 | wpwrak | sure. it's just polite to let him know of things we already know are coming but that haven't been mentioned yet. "keep him in the loop." |
| 18:11.34 | DocScrutinizer05 | that's why we don't specify part numbers but rather abstract functions |
| 18:11.49 | DocScrutinizer05 | sure |
| 18:12.35 | DocScrutinizer05 | thus I said "comsider that type of tiny debug LED an arbitrarily used building block to throw in wherever needed" |
| 18:13.10 | DocScrutinizer05 | Nik will not have any problems with this, it's basically just copy&paste |
| 18:13.41 | DocScrutinizer05 | similar complexity to placing a buffer capacitor next to a VDD pin |
| 18:13.51 | wpwrak | LED + 1-2 FETs. small, but not negligible. (in terms of space, not in terms of design work at the schematics level) |
| 18:14.08 | DocScrutinizer05 | one transistor |
| 18:14.20 | DocScrutinizer05 | one or two R |
| 18:14.22 | DocScrutinizer05 | one LED |
| 18:14.28 | DocScrutinizer05 | see protoV1 |
| 18:15.15 | DocScrutinizer05 | we had that and I'd be surprised when Nik thought we don't need it in V2 anymore |
| 18:15.55 | DocScrutinizer05 | building a prototype implies such debugging gear |
| 18:16.25 | DocScrutinizer05 | we don't need to specify every testpoint and every debug LED |
| 18:16.50 | wpwrak | at some point, we do :) |
| 18:17.02 | DocScrutinizer05 | Nik is an expoerienced EE |
| 18:17.49 | DocScrutinizer05 | I have no doubt he will come up with that stuff by himself. He did in V1 |
| 18:18.26 | DocScrutinizer05 | I'm afraid you're over-specifying what we want Nik to do, and in the end he says "they asked for it, they get it" |
| 18:21.34 | wpwrak | as i said, the two of you should probably get together and discuss at the block diagram level once it's done and each had a good look at it. then you can sort out any remaining doubts. |
| 18:21.35 | DocScrutinizer05 | like in "werner: 'we want 5 debug LED with 2 FET' Nik: ' umm! I'd use one transistor and would place 8 LED like that for all that stuff I see, but... OK it's clearly written in spec what they want' " |
| 18:22.56 | DocScrutinizer05 | I think Nik and I prefer "the real stuff": eagle schematics |
| 18:22.57 | wpwrak | btw, the 2 FETs would be for active-low with a signal voltage not compatible with LEDs (e.g., 1.8 V, which would be hard on the edge for most LEDs) |
| 18:23.50 | DocScrutinizer05 | hmmm .oO(???) |
| 18:25.00 | DocScrutinizer05 | ooh, I see |
| 18:25.41 | DocScrutinizer05 | I'd prolly rather use a bus driver chip or sth like that then |
| 18:25.43 | wpwrak | you can do it with one transistor (shorting the LED), but that's a bit ugly |
| 18:26.40 | DocScrutinizer05 | sth of the class 74245 or somesuch |
| 18:27.15 | wpwrak | i really hope nik doesn't plan to solder the board manually ;-) |
| 18:27.31 | DocScrutinizer05 | no idea, really |
| 18:28.13 | DocScrutinizer05 | I'd not try to. But then that's me |
| 18:32.50 | DocScrutinizer05 | I guess he will use VPS |
| 18:34.26 | wpwrak | that's @ GC ? or does he have a cooking pot for VPS at home ? |
| 18:34.47 | DocScrutinizer05 | that's why you use a hw house like GDC, they all have their "secrets" :-) |
| 18:35.26 | wpwrak | maybe he's just got a really nice old pizza oven, made of stone :) |
| 18:36.00 | wpwrak | anyway, afk for a bit. gotta clean my den, visitor coming. |
| 18:36.04 | DocScrutinizer05 | hw house knows what can get done and how to do it, they however only offer the "what" and customer doesn't care or get to know about the "how" |
| 19:12.22 | DocScrutinizer05 | ooh |
| 19:12.53 | DocScrutinizer05 | wpwrak: we should use THREE ina231 |
| 19:13.32 | DocScrutinizer05 | since we have three VDD inputs for modem which can help us gain more detailed info about what's going on |
| 19:16.48 | wpwrak | seem that we'll soon need the weird address modes of the INA231, too :) btw, any monitor on WLAN ? |
| 19:17.04 | wpwrak | and while we're at it, how about RF monitoring ? |
| 19:18.20 | wpwrak | how any ALERT interrupts from modem monitor to CPU ? one, shared, or one for each ? |
| 19:26.30 | DocScrutinizer05 | I'm much a friend of shared IRQ lines |
| 19:27.06 | DocScrutinizer05 | as long as no ultra-low latency in IRQ service handling is needed |
| 19:28.00 | DocScrutinizer05 | th "weird" address modes of INA231 been alrady checked by me and found matching for the intended purpose |
| 19:29.53 | DocScrutinizer05 | RF monitoring will need some careful design and dimensioning of a pretty simple diode-AM-demodulator style circuitry |
| 19:30.18 | wpwrak | is the RF monitoring something we want in V2 ? |
| 19:30.24 | DocScrutinizer05 | and a dedicated IRQ, plus maybe even an A/D if we got some spare |
| 19:30.38 | wpwrak | that DVB chip ;-) |
| 19:30.49 | DocScrutinizer05 | V2 yes, if we can get it in |
| 19:31.28 | *** join/#neo900 thrakcattack (~u@80-121-4-187.adsl.highway.telekom.at) |
| 19:32.42 | DocScrutinizer05 | I might provide some circuit suggestions to test |
| 19:44.27 | DocScrutinizer05 | RF is always voodoo. At least to me, though others seem to concur |
| 19:45.04 | DocScrutinizer05 | Ideally a RF engineer would design this particular bit |
| 19:46.15 | DocScrutinizer05 | though in the end reality proves that virtually almost anything is a fine RF detector ;- |
| 19:46.33 | DocScrutinizer05 | ;-) |
| 19:47.27 | DocScrutinizer05 | DVB chip however has way too high power consuption, whereas this detector needs to operate at next to zero quiescent current |
| 19:48.24 | DocScrutinizer05 | I guess in the end it will be one or two transistors and a schottky |
| 19:48.38 | DocScrutinizer05 | maybe a bead |
| 19:48.49 | DocScrutinizer05 | and of course a few capacitors and R |
| 19:56.04 | DocScrutinizer05 | heck, who said we need FETs for the debug LEDs? Not me anyway |
| 20:23.08 | wpwrak | indeed, just "dead simple driver" :) |
| 21:05.17 | DocScrutinizer05 | I explicitly said "transistor" |
| 21:05.38 | DocScrutinizer05 | and teher are like 5 examples in protoV1 and I think also protoV2 already |
| 21:05.56 | DocScrutinizer05 | there* |
| 21:06.29 | DocScrutinizer05 | and Nik will know what to use anyway |
| 21:06.57 | DocScrutinizer05 | "LED level indicator for digital signals" is all we need to specify |
| 21:07.31 | DocScrutinizer05 | it's up to Nik to "design" the circuit for that |
| 21:08.03 | DocScrutinizer05 | I think I explained this roundabout two dizen times now |
| 21:08.29 | DocScrutinizer05 | no part numbers, no implementation details, just abstract function descriptions |
| 21:08.58 | DocScrutinizer05 | implementation suggestion is up to GDC |
| 21:10.22 | DocScrutinizer05 | then I review that or maybe give a *suggestion* beforehand how we *could* implement a particular function. When during review stuff looks sub-optimal, i'll discuss implementation details with Nik |
| 21:11.34 | DocScrutinizer05 | even number and signals to connect to such a "LED level indicator for digital signals" is a subhect for review phase |
| 21:12.39 | *** join/#neo900 defaboy_ (deafboy@cicolina.org) |
| 21:13.04 | DocScrutinizer05 | thus - if you think that#s *really* needed - you can specify sth like "n (TBD, <20) LED level indicators for various digital signals, as needed" |
| 21:14.21 | DocScrutinizer05 | if that's using FETs then, or transistors, or even 74145 or whatever, or simply a series R and LED to a open collector signal that can drive 2mA |
| 21:14.28 | DocScrutinizer05 | up to Nik |
| 21:14.49 | DocScrutinizer05 | 74244, or 45, or sth |
| 21:15.05 | DocScrutinizer05 | actually not my call initially |
| 21:15.24 | DocScrutinizer05 | I'm sharing suggestions on such details, when I think it could help Nik |
| 21:16.12 | DocScrutinizer05 | then I review schematics and discuss stuff that seems to have any sort of issue, or could get implemented way cheaper or simpler or better in my book |
| 21:17.32 | DocScrutinizer05 | when it's only a minor difference in personal style, I will accept Nik's suggestions |
| 22:04.42 | wpwrak | (LEDs) yeah, sorry about the FET. anyway, if he thinks he needs something else, i'd expect him to speak up. i didn't mention any additional details, like placement and such. that's entirely up to you and him. |
| 23:37.03 | DocScrutinizer05 | np |
| 23:37.26 | DocScrutinizer05 | thanks for the great job you're doing! |
| 23:46.49 | *** join/#neo900 silviof (~silviof@unaffiliated/silviof) |
,50a4bb269610f.jpg){kind=link}
