| houkime | She also plays MMOs on it) It is some xiaomi mid-range stuff. 250$ | 00:00 |
|---|---|---|
| houkime | I mean even if it is not really often now, it quickly becomes ok to have a constant connection. | 00:01 |
| Joerg-Neo900 | O just can tell my Cat S60 with a quite beefy 3000some mAh battery can do hotspot for maybe 4 hours, or less when much data transferred | 00:02 |
| Joerg-Neo900 | *I* | 00:02 |
| Joerg-Neo900 | >>The S60 comes loaded with a hefty 3,800mAh battery.<< http://www.trustedreviews.com/reviews/cat-s60-battery-and-conclusion-page-4 | 00:04 |
| Joerg-Neo900 | also | 00:06 |
| Joerg-Neo900 | ~power | 00:06 |
| infobot | somebody said power was http://wiki.maemo.org/N900_Hardware_Power_Consumption | 00:07 |
| houkime | There should be some data rate that is tolerable for the battery. Like, datarate which increases your daily energy consumption only by 10% or so. | 00:17 |
| houkime | one can calculate this average datarate and see how feasible is this slow-but-frequent network. | 00:18 |
| houkime | the thing is that you can send packets different routs to manage the load | 00:19 |
| houkime | and if we're speaking about phones, number of nodes and route alternatives can be large. | 00:19 |
| Joerg-Neo900 | err route alternatives? | 00:20 |
| houkime | *alternative routes | 00:20 |
| Joerg-Neo900 | I think the most important factor is if the WLAN is a client or an AccessPoint aka AdHoc mode | 00:20 |
| houkime | when you can connect through A and B but can through C and D | 00:20 |
| Joerg-Neo900 | I don't see how this applies to a WLAN device | 00:21 |
| Joerg-Neo900 | note how power saving mode in N900 WLAN makes the device WLAN deep-sleep more than 90% of time, only waking up for a short moment to check if the beacon from AP it's associated to has the "data pending" flag set | 00:23 |
| Joerg-Neo900 | obviously in AdHoc and AP mode the device needs to send beacons itself instead | 00:24 |
| Joerg-Neo900 | refer to extreme increase in power consumption when N900 WLAN is *NOT* associated to an AP and needs to run the receiver all the time | 00:25 |
| Joerg-Neo900 | funny enough the complex and high bandwidth receiver eats more power than the transmitter | 00:26 |
| Joerg-Neo900 | and this seems to be valid for all existing WLAN chipsets | 00:26 |
| houkime | on phones you can probably do wakeup-calls via cell-related circuitry instead? | 00:29 |
| Joerg-Neo900 | not when you want to do a peer2peer mesh | 00:31 |
| Joerg-Neo900 | when you just want to route a call via AP to phone's WLAN and to e.g. a SIP client there, you don't need any fancy tricks, my N900 is capable of doing this for like 3 days in standby on WLAN medium PowerSavingsMode | 00:32 |
| Joerg-Neo900 | prolly 5+ days when I shut down IRC | 00:33 |
| Joerg-Neo900 | 7 if I shut down cell as well | 00:34 |
| Joerg-Neo900 | not keep an established callof course, just receive an imbound call any time, in standby | 00:36 |
| houkime | i want phones to be able to resend packets to other phones but without having to constantly run WLAN receiver. | 00:38 |
| Joerg-Neo900 | dang, I got rsyslog-ng rules to route all my server remote syslogs to a separate file. It works for all messages, except for those which still show up in default syslog file: 2018-06-17T23:02:12+02:00 UbiqPKD kernel: last message repeated 12 times | 00:39 |
| Joerg-Neo900 | how would you resend a WLAN data packet to a phone that doesn't constantly run WLAN receiver? | 00:40 |
| Joerg-Neo900 | I mean, you could power up WLAN every 30s or somesuch, which would maybe cut the WLAN power consumption by half, but gives you a average 15s latency per hop | 00:41 |
| houkime | Via making use of the phone already listening to his cell. Imitate a cell signal which onboard soft will decode as a wakeup for WLAN. | 00:41 |
| Joerg-Neo900 | omotate? that's neither possible nor legal | 00:42 |
| Joerg-Neo900 | imitate* | 00:42 |
| Joerg-Neo900 | and cell modem employs exactly same deepsleep methods, shutting down the RX for several seconds between very short listening intervals | 00:43 |
| Joerg-Neo900 | the standby times cranked up from 10h to 5 days when that feature got introduced around 2000 minus a few years | 00:44 |
| Joerg-Neo900 | and it's the reason why it takes up to 10s until your hear a call signal when you place a call to a mobile phone | 00:45 |
| Joerg-Neo900 | so you don't gain anything much by switching from WLAN to GSM_ff | 00:46 |
| Joerg-Neo900 | plus to imitate a BTS you as well need to constantly send "beacons" (not really beacons) on the cell's service channel | 00:47 |
| Joerg-Neo900 | the only commonly available low-energy_standby medium-range RF protocol is BLE | 00:48 |
| Joerg-Neo900 | I don't know how they do it but they manage to run their receivers pretty humble on power consumption | 00:50 |
| houkime | thay may use field-powered receivers actually. | 00:51 |
| Joerg-Neo900 | don't | 00:51 |
| houkime | so that each session is initiated with a strong pulse | 00:51 |
| Joerg-Neo900 | NFC does | 00:51 |
| Joerg-Neo900 | BLE not | 00:51 |
| Joerg-Neo900 | I raher think that pairing is an important part that allows the receiver to listen to very narrow band and well defined wake signal only | 00:52 |
| houkime | nfc does, but infc is short range. I mean one can make a receiver being awaken by a strong pulce on a given frequency that actually powers up a pin for a moment. | 00:53 |
| Joerg-Neo900 | so sleep for 99ms, check 1ms for a well known pattern on a well defined frequency | 00:53 |
| houkime | nono, i mean if you have some tuned antenna you can basically power a wakeup latch for a moment with a wakeup pulse itself. | 00:54 |
| Joerg-Neo900 | would require only 100ms of WAKE signaling from the sender, and only a 1% duty cycle of a simple receiver | 00:55 |
| houkime | I mean it can be literally sleeping intil brutally poked to action. | 00:55 |
| Joerg-Neo900 | you can, but signal amplitude drops with almost cube exponent of distance | 00:55 |
| Joerg-Neo900 | and BT only has max 100mW usually | 00:56 |
| houkime | caps | 00:56 |
| houkime | can store some power and release as a pulse | 00:56 |
| Joerg-Neo900 | no | 00:56 |
| Joerg-Neo900 | theey don't do this | 00:56 |
| Joerg-Neo900 | it would fail in 3m distance even for a 5W pulse | 00:57 |
| Joerg-Neo900 | and it would void any hope for getting a certification of the BT transmitter | 00:58 |
| Joerg-Neo900 | but basically they could do something almost similar, using a pretty passive receiver design for the narrow band receiving | 00:59 |
| Joerg-Neo900 | such passive receiver wouldn't have a sufficient bandwidth and sensitivity for any useful data transfer rate, but it can sense a known pattern like 9800Bd UART characters | 01:01 |
| Joerg-Neo900 | 9600* | 01:01 |
| houkime | ok, so we might need an open versionof this. | 01:01 |
| Joerg-Neo900 | sou you could send the character "!" serially encoded with start and stop bit for a 100ms and receiver could sense that within 2ms listening | 01:02 |
| Joerg-Neo900 | TX would send a 100 "!" and each takes 1ms, RX listens for 2ms and can receive one complete char/byte | 01:03 |
| Joerg-Neo900 | if RX doesn't receive the "!" then it goes to sleep for 98ms again | 01:04 |
| houkime | understood. | 01:04 |
| Joerg-Neo900 | for even better duty cycle, the RX checks for a carrier frequency and if none detected it can sleep again after as little as 0.01ms | 01:05 |
| houkime | seems like latency will be a thing again though. Many hops, each is taking minimum 2 ms. | 01:07 |
| houkime | in a combined net of routers phones and doishlines might be ok though | 01:08 |
| houkime | *dishlines | 01:08 |
| Joerg-Neo900 | minimum isn't even relevant here. average would be 50ms in this scheme | 01:09 |
| Joerg-Neo900 | but yu can tune those parameters in a wide range, like 2 or 3 magnitudes | 01:10 |
| Joerg-Neo900 | and actually a low bandwidth 'passive' receiver might be so humble you could run it 100% duty cycle | 01:11 |
| Joerg-Neo900 | then you just have the latency from cranking up the high bandwidth RX after you receive a WAKE | 01:11 |
| Joerg-Neo900 | and I think BT4.0 does something like this with WLAN actually | 01:12 |
| Joerg-Neo900 | or was it BT5? | 01:12 |
| Joerg-Neo900 | anyway wake signal on BT, real data communication on WLAN | 01:13 |
| Joerg-Neo900 | but yes, mesh networks have gigh latencies, that's design immanent | 01:16 |
| Joerg-Neo900 | high* | 01:16 |
| Joerg-Neo900 | you already run into this probem when using WLAN repeaters | 01:17 |
| Joerg-Neo900 | each repeater adds 1 (at least) to the N in 1/N bandwidth of the network | 01:18 |
| Joerg-Neo900 | so wuth 4 repeaters you get 1/5 of the genuine bandwidth | 01:19 |
| Joerg-Neo900 | or 1/10 | 01:19 |
| Joerg-Neo900 | since every data package gets transferred no earlier than it been completely received, on a repeater | 01:20 |
| Joerg-Neo900 | usually | 01:20 |
| Joerg-Neo900 | *starts getting transferred* | 01:21 |
| houkime | soo... protocols need to be dumbed down/redone to support faster hopping? | 01:25 |
| houkime | like "don't know what it is will just repeat it it it hits target?" | 01:26 |
| houkime | so we have a packet and an antipacket "received" spreading through net | 01:26 |
| Joerg-Neo900 | as long as you don't find a physical trick to receive and send data packages same time on same Radio access Technology, you're short of luck with speeding up stuff | 01:27 |
| Joerg-Neo900 | some WLAN repeaters use 2.4->5GHz to avoid that problem | 01:28 |
| Joerg-Neo900 | or vice versa | 01:28 |
| Joerg-Neo900 | making a WLAN receive packets on 2.4 GHz while sending on 2.4GHz+20MHz usually fails for physical reasons of RX pre-amp getting saturated | 01:30 |
| Joerg-Neo900 | even when you use physically separated antennas that are like 20cm apart from each other | 01:31 |
| Joerg-Neo900 | s/pacjages/packets/ | 01:31 |
| Joerg-Neo900 | so for all usual scenarios, it's TX and RX are mutually exclusive | 01:33 |
| Joerg-Neo900 | in a mesh you also need to invest time into routing, unless you want to send a 'broacast' packet avalanche through the complete mesh | 01:45 |
| Joerg-Neo900 | and you for sure don't want a packet to run in circles through the mesh ad infinitum | 01:46 |
| houkime | avalanche+ lifetime counter? | 01:47 |
| houkime | -1 every hop | 01:47 |
| houkime | though too much stress | 01:48 |
| Joerg-Neo900 | possible. needs reading of at least the packet preamble with the counter, before you can start retransmitting the decremented counter packet | 01:48 |
| Joerg-Neo900 | you don't get around the latency per hop | 01:48 |
| Joerg-Neo900 | then you also probably don't want to relay/retransmit packets that have a RX error, so you need to receive the complete packet, do the checksum calculation and worst case ask sender to retransmit, before you start relaying | 01:52 |
| houkime | AAAAAAAAAAAAAPacket, each time one letter gets reduced. | 01:55 |
| houkime | then avalanche will produce shorter and shorter packets and no checks are needed | 01:56 |
| Joerg-Neo900 | go simulate this, with each node havong 5 neighbours, and a node count > 50. You'll pull your hair | 01:57 |
| Joerg-Neo900 | go send a second and a third packet from different origin nodes concurrently | 01:58 |
| Joerg-Neo900 | the thing will explode right into your face | 01:58 |
| Joerg-Neo900 | do you kknow chain letters? | 01:59 |
| Joerg-Neo900 | or, simple example. Flu waves sweeping through a country | 02:00 |
| Joerg-Neo900 | those are even harmless since you usually don'T catch same flu a second time | 02:00 |
| Joerg-Neo900 | read about internet routing particularly of multicast packets | 02:02 |
| houkime | We can actually make use of WIFI being geografical. If it is not an AAAAAAAAAPacket but an ABCDEFGpacket with letters being assigned by your location in a deterministic algorithm. | 02:04 |
| houkime | one hop still consumes one letter. | 02:05 |
| houkime | but repeat is not following if letters don't match. | 02:05 |
| houkime | though this will need special periodic pulces to update routing | 02:07 |
| Joerg-Neo900 | protocols for mash networks exist. Refer for example B.A.T.M.A.N. | 02:07 |
| Joerg-Neo900 | mesh* | 02:07 |
| houkime | ok. will look into it later. | 02:13 |
| houkime | can you explain a bit a purpose of C1122 and R1124? They are between agnd and agnd | 16:38 |
| Joerg-Neo900 | off topic: please sign https://www.change.org/p/european-parliament-stop-the-censorship-machinery-save-the-internet?utm_source=share_petition&utm_medium=copylink&utm_campaign=share_petition - read https://blog.github.com/2018-03-14-eu-proposal-upload-filters-code/ for more context. | 17:55 |
| houkime | let's hope petition makes it through. Ok, now Microsoft-led Github will represent oss developers in debates over whether or not code uploads need to be checked for copyright infringements. What can possibly go wrong | 19:07 |
| houkime | Joerg-Neo900: soo... what' with C1122 and R 1124? Even with star connection this doesn't seem to make much sense - therefore I son't really know what configuration is needed for this to work as intended. | 19:11 |
| Joerg-Neo900 | will check | 19:12 |
| Joerg-Neo900 | :-/ | 19:13 |
| Joerg-Neo900 | eeshow: error while loading shared libraries: libgit2.so.21: cannot open shared object file: No such file or directory | 19:13 |
| Joerg-Neo900 | make: *** [Makefile:56: view] Error 127 | 19:13 |
| houkime | recompile | 19:14 |
| Joerg-Neo900 | yeah | 19:14 |
| Joerg-Neo900 | I see... C1122 R1124 are probably cruft for full symmetry of the differential pair line that is mic signal | 19:17 |
| houkime | R1124 actually breaks geometrical symmetry.( | 19:23 |
| houkime | hm, or maybe not | 19:24 |
| houkime | shouldn't C1108 also lead to agnd instead of gnd? | 19:27 |
| houkime | seems like in terms of symmetry the biggest offence is... err... big video switch | 19:43 |
| Joerg-Neo900 | yes, should be AGND | 19:44 |
| Joerg-Neo900 | oops C1108, sorry need to check | 19:45 |
| Joerg-Neo900 | yes, AGND of course | 19:45 |
| Joerg-Neo900 | good catch :-) | 19:46 |
| Joerg-Neo900 | thanks! | 19:46 |
| Joerg-Neo900 | actually could be both, but AGND makes more sense | 19:48 |
| houkime | so, how is "differentiality" is maintained while mic+ goes through video switch and mic- doesn't? | 19:48 |
| Joerg-Neo900 | try as good as it gets. It's basically a concept, not a recipe | 19:52 |
| houkime | how at all a differential line can have gnd as - . | 19:53 |
| houkime | I mean, they are supposed to be antiphase | 19:53 |
| houkime | but good gnd is always in place | 19:53 |
| houkime | it doesn't oscillate. | 19:53 |
| Joerg-Neo900 | it's about minimizing current interference from digital to analog GND, and trying to keep the analog signal and GND currents as parallel and close to each other as possible. It's not a impedance matched differential line though | 19:55 |
| Joerg-Neo900 | makes sense? | 19:56 |
| houkime | so that current xcancel each other in farfield? | 19:57 |
| Joerg-Neo900 | yes | 19:57 |
| Joerg-Neo900 | exactly | 19:57 |
| Joerg-Neo900 | as much as possible | 19:57 |
| Joerg-Neo900 | the magnetic fields | 19:58 |
| houkime | well, will try. | 19:59 |
| Joerg-Neo900 | think of it like faintly similar to a shielded coax cable | 19:59 |
| Joerg-Neo900 | or rather: twisted pair | 19:59 |
| Joerg-Neo900 | the better the "twisting" the smaller the susceptibility to any magnetic interference | 20:00 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!