Kabouik- has quit [Ping timeout: 255 seconds]
infobot has quit [Read error: Connection reset by peer]
infobot has joined #neo900
<galiven> houkime: I follow the channel to try to keep up, but I miss sometimes and it would be nice to have more regular updates. Something like subscribing to a bug tracker that was regularly updated or even the commit message (without files) from the private git. I use nextcloud as a feed reader so subscribing to the atom feed was easy enough except that it's not updating.
wiewo has quit [Ping timeout: 255 seconds]
wiewo has joined #neo900
Pali has quit [Ping timeout: 260 seconds]
jonwil has quit [Quit: ChatZilla 0.9.93 [SeaMonkey 2.49.3/20180412182658]]
illwieckz has quit [Ping timeout: 260 seconds]
himcesjf_ has joined #neo900
him-cesjf has quit [Ping timeout: 260 seconds]
himcesjf_ is now known as him-cesjf
illwieckz has joined #neo900
ArturShaik has joined #neo900
pagurus has quit [Ping timeout: 240 seconds]
pagurus has joined #neo900
knttl has quit [Ping timeout: 256 seconds]
knttl has joined #neo900
dos1 has quit [Ping timeout: 268 seconds]
dos1 has joined #neo900
paulk-gagarine-s has joined #neo900
paulk-gagarine has quit [Ping timeout: 256 seconds]
jcarpenter2 has quit [Read error: Connection reset by peer]
jcarpenter2 has joined #neo900
<Joerg-Neo900> the commit messages from "private" git on neo900 are visible in public git
paulk-gagarine-s has quit [Quit: Leaving]
paulk-gagarine has joined #neo900
_whitelogger has joined #neo900
l_bratch has quit [Quit: Leaving]
l_bratch has joined #neo900
jonsger has joined #neo900
illwieckz has quit [Ping timeout: 276 seconds]
jonwil has joined #neo900
Pali has joined #neo900
DocScrutinizer05 has quit [Quit: EEEEEEK]
_Chris_ has joined #neo900
DocScrutinizer05 has joined #neo900
__Chris has quit [Ping timeout: 265 seconds]
houkime has joined #neo900
<houkime> Joerg-Neo900: it shows only master commits and doesn't allow to switch branches.
<houkime> meanwhile all progress is on another branch (i.e. mine)
<Joerg-Neo900> houkime: yes, it's somewhat limited. We didn't bother to over-engineer that part
<Joerg-Neo900> in the end it's again a matter of "spend 1 man week for brushing out all bugs from automation, vs simply do it manually a maybe 50 times 5 minutes for each time"
<Joerg-Neo900> in rreal life it's usually rather 4 man weeks vs 15 times one minute
<houkime> well, i can try to represent ALL commits as issue fixes so that they're somewhat visible in my issue tracker.
<houkime> (however again this problem is just a side effect of gitolite which is much more PITA to configure than it should be and than most other gitservers are)
<atk> the commit copying is not implemented via gitolite
<atk> it's implemented via git hooks and magic scripts
<atk> It's a "cool hack" which is a bit of a PITA to maintain
<Joerg-Neo900> and again this bitching about gitolite
<Joerg-Neo900> :-S
<houkime> I mean, there wouldn't probably be even need for a hack otherwise.
<Joerg-Neo900> listen houkime, you're not even involved in git administration. Please stop bullying
<Joerg-Neo900> if you want something changed, tell us which particular function shall change in which way
<Joerg-Neo900> emphasis on "function", not "subsystem/tool used"
Kero has quit [Ping timeout: 260 seconds]
<houkime> well, there's a function "notifications on commits on non-master branch" which a member of a community expressed interest in. You've already answered that using your subsystems it is a PITA to implement and I better do things manually.
<Joerg-Neo900> no, for sure I didn't
<houkime> <Joerg-Neo900> in the end it's again a matter of "spend 1 man week for brushing out all bugs from automation, vs simply do it manually a maybe 50 times 5 minutes for each time"
<Joerg-Neo900> the system works as designed
<Joerg-Neo900> and as intended
<Joerg-Neo900> there is no requirement of "notifications on commits on non-master branch"
<Joerg-Neo900> actually we explicitly ruled that out when we set stuff up
<houkime> So galiven's perfectly logical request is not a requirement for you?
<Joerg-Neo900> please quote that request, I seem I can't find it
<atk> houkime: I don't know of any git server which allows filtering commits based on the extension of the file changed and reproducing the commits without that file change in another repository
<atk> or any git server which just doesn't serve parts of the repository based on file extension
<atk> the only way to implement that seems to be via some hack and I don't think changing the git server would make any difference there
<atk> but if you have some idea for simplifying this, I'll be happy to listen
<Joerg-Neo900> ideas for simplifying would need a basis of understanding the requirements and current system first
<houkime> 01:43 <galiven> houkime: I follow the channel to try to keep up, but I miss sometimes and it would be nice to have more regular updates. Something like subscribing to a bug tracker that was regularly updated or even the commit message (without files) from the private git. I use nextcloud as a feed reader so subscribing to the atom feed was easy enough except that it's not updating.
<Joerg-Neo900> the design was to have an internal git repo where layouters can commit to, and all except footprints and layout files get propagated to public repo
<atk> hmm
<atk> I for the commit log I guess that would not be hard to do as a quick ATOM fieed
<atk> feed*
<Joerg-Neo900> houkime: you're aware that our git system does *exactly* what galiven asked for?
<houkime> it doesn't support non-mastrer branches and thereby it fails to act as a newsfeed.
<houkime> simple as that
<Joerg-Neo900> there been no mentioning of any of that in galiven's post
<Joerg-Neo900> simple as that
<atk> wait wait, if all houkime and galiven want is just a commit log for all branches without any file information then this would be much easier than fixing the existing stuff and expanding it to multiple branches
<atk> I don't mind putting something together with some quick PHP for that
<houkime> atk: exactly that
<Joerg-Neo900> modulo we decided quite mindfully against this
<atk> Joerg-Neo900: may I know why it was decided against?
<Joerg-Neo900> because metacollin as well as me didn't want *all* branches and repos to get published, it's an opt-in not an opt-out concept
<atk> alright, I can make it use a whitelist of branches, how about that?
<Joerg-Neo900> ok with me
<houkime> ok
<atk> I'll start looking into it then, I'll test on my own server to implement something and then I'll look at integrating it into the neo900 server infrastructure
<Joerg-Neo900> ta!
<Joerg-Neo900> atk: keep in mind that cleaning oopsies is obviously quite painful in git. we already once had files leaking and almost didn't manage to clean them out again, had to rebuild the complete repo iirc
<atk> This won't show any files so there won't be a problem
<atk> this will just be a commit log with file names
<Joerg-Neo900> good
<atk> As long as someone doesn't put footprint data in the commit message, there won't be a problem
<Joerg-Neo900> :-D
<atk> and actually, pygit2 might be a good option for writing a slightly nicer and less error prone whitelist based repo replication script
<atk> but I'll look at it once I work out how to get this atom feed working
illwieckz has joined #neo900
l_bratch has quit [Quit: Leaving]
l_bratch has joined #neo900
l_bratch has quit [Quit: Leaving]
l_bratch has joined #neo900
<Joerg-Neo900> a last comment: >>it doesn't support non-mastrer branches<< is incorrect. We deliberately *added* a line (iirc) to the magic script code to exclude branches from getting published
<Joerg-Neo900> for sure it been considerd and carefuly taken care about to make sure it acts like intended, also in this branches-regard
<Joerg-Neo900> this constant assumption we were simply incompetent to set up stuff the way somebody else thinks was "The Correct Way" is pretty annoying
<Joerg-Neo900> I'm for sure no git expert, but this >>however again this problem is just a side effect of gitolite<< and >>there wouldn't probably be even need for a hack otherwise<< are not solicited, not founded and not appreciated
houkime has quit [Ping timeout: 264 seconds]
<Joerg-Neo900> atk: sorry I missed to really notice (I read but somewhat ignored it) the >>if all houkime and galiven want is just a commit log for all branches without any file information then this would be much easier<< part. Of course this is much easier and I have not much concerns about it in any way
houkime has joined #neo900
<Joerg-Neo900> stoll it would be fine if we have a whitelist for repos to aggregate in such commitlog summary webpage
<Joerg-Neo900> still*
<Joerg-Neo900> there might be (and maybe already have been) "tmp" repos that ere not at all meant to get published
<Joerg-Neo900> not sure about branches
illwieckz has quit [Read error: Connection reset by peer]
illwieckz has joined #neo900
Kero has joined #neo900
illwieckz_ has joined #neo900
illwieckz has quit [Ping timeout: 260 seconds]
illwieckz_ is now known as illwieckz
louisdk has joined #neo900
jonwil has quit [Quit: ChatZilla 0.9.93 [SeaMonkey 2.49.3/20180412182658]]
louisdk has quit [Quit: Ex-Chat]
louisdk has joined #neo900
MonkeyofDoom has joined #neo900
louisdk has quit [Ping timeout: 240 seconds]
louisdk has joined #neo900
<galiven> Joerg-Neo900: atk: A log of changes without the files would be nice just to see that things are happening, even if they're happening in houkime's branch instead of master. I know the files are sensitive and we don't want to release them too early, but http://neo900.org/git/ee/ has its last commit at 9 months ago, so it doesn't seem like anything is going on.
<galiven> Maybe even in the uBlog which I subscribe to and is right on the main neo900.org page.
<Joerg-Neo900> alas microblog is the most fubar thing in whole site
<Joerg-Neo900> but maybe atk can do a little miracle and revive it again for this purpose
<Joerg-Neo900> in 9 out of 10 cases, my posts to microblog didn't make it at all I.E got rejected with obscure errors, or got stuck in the tube and piled ip there not showing on webpage, or in rare cases made it but with wrong author
<Joerg-Neo900> so I gave up on it when I asked a 5th time to have it fixed and nothing happened
<galiven> Ahhh :-( I much prefer having uBlog compared to relying on giant evil Twitter.
<Joerg-Neo900> twitter is completely unknown to me
<Joerg-Neo900> but I think a large part of uBloh's fubarness was from twitter integration
<galiven> I know others use it a lot but I avoid it. Surprisingly apparently Nikolaus uses it, there's a link on the top of goldelico.com for @goldelico.
<Joerg-Neo900> and the ever changing twitter API
<Joerg-Neo900> wow
<Joerg-Neo900> anyway atk is looking into it, so you soon will find something you should probably like
<atk> Yes, I have a thing sort of working, it just needs a bit more work, but some life responsibilities got in the way.
<Joerg-Neo900> no hurries :-)
louisdk has quit [Ping timeout: 240 seconds]
<Joerg-Neo900> tbh I'm not sure at all if going twitter and facebook was any smart move for Neo900 to start with. In the end both are rather what we want to fight than what we want to support
<Joerg-Neo900> but well... when I see companies having "privacy and decentralization" as core of their corporate identity going all google-doc for their internal stuff
<houkime> seems like federated social networking is needed just like people want to federate git servers here: https://github.com/git-federation/gitpub/issues
<houkime> via reaching consensus on the protocols etc.
<houkime> so that you can publish on minor or even self-hosted network and still be heard everywhere else.
<galiven> I watch #neo900 and #openphoenux on diaspora*. Don't bother with facebook anymore and never got on the Twitter bandwagon in the first place.
illwieckz has quit [Ping timeout: 256 seconds]
<jonsger> galiven: you are on diaspora?
illwieckz has joined #neo900
<galiven> Joined a while ago because facebook is terrible, but I just follow a couple tags to see if anything interesting has happened lately.
<galiven> The #linux tag is a bit too noisy though, so I don't see much that's interesting.
<houkime> found probably the only reasonable position for nfc subsystem. See how long till i find some terrible thing that disallows it.
<houkime> checked out diaspora wikipage. Looks like a nice thing.
<houkime> Personally I'm more looking forward to decentralised videohostings to put down youtube. That would be really nice although probably hardware reqs for video server are way too high.
<houkime> man, google really makes tons of money with its specialised video datacenters and does not play nice.
<houkime> maybe some cheap oshw server hardware is what is needed here.
ArturShaik has quit [Ping timeout: 248 seconds]
<atk> hmm
<atk> I don't really actually think google makes any money on youtube
l_bratch has quit [Remote host closed the connection]
l_bratch has joined #neo900
xmn has joined #neo900
<Joerg-Neo900> they must do, otherwise how would they pay to professional youtube contributors?
<Joerg-Neo900> I think their ads on YT are not for free
<Joerg-Neo900> and they are way more efficient than banner ads, with that nasty "you can skip this video on 5s..."
Kabouik- has joined #neo900
Kabouik_ has joined #neo900
Kabouik- has quit [Ping timeout: 245 seconds]
<atk> Google is a big company which makes lots of money elsewhere. As of 2015 youtube was still only breaking even in terms of revenue. Not sure about right now.
<Joerg-Neo900> ooh
<atk> Although maybe their aggressive tactics recently have improved the situation.
<atk> Back in 2015 things like youtube red were in their infancy and the adpocalypse hadn't happened yet.
<atk> But the website's popularity as a place for music videos and mainstream media channels had been growing since then
<atk> and those don't get demonitised and bring lots of ad views
<houkime> if one needs to go aggressive only to make some profit even if it has a size economy bonus than probably slashing down essential costs like hardware, buildings, electricity and bandwith is the only way to make a real competition.
<houkime> *then
<atk> Yeah, competing with youtube would be difficult merely due to how expensive it would be and how difficult it would be to monetize while competing with it
<houkime> oshw community-done-all-rnd servers, 3d-printed buildings, self-powered via solar or sth, on the Musk's free Starlink ISP
<atk> Hmm, I wouldn't trust musk when he says something will be free
<atk> He has a talent for underestimating the running cost of his ambitious ideas
<atk> even if it starts of free, that's not a guarantee
<houkime> satellites have no maintainance as of now.
<atk> well.. you still have to launch them and then replace them
<houkime> I think the solution to replacement problem would be to launch them high enough and make dynamic (non-geostationary) links possible.
<houkime> so that they don't need to correct orbit and refuel.
<houkime> spacecrafts themselves as history shows are quite reliable.
<houkime> basically - more reliable than any ground infra.
<houkime> In some time crowdfunded satellites should also become possible.
<houkime> so that all network lives off donations
<houkime> *on
<houkime> technically you can use not a dish but a phased array to communicate. And all adjustments will be done software-level without moving parts.
<houkime> so even if orbit deterioration occurs or satellite is not in a fixed point in the sky soft will handle it all.
<houkime> this way you can make satellites fly much higher and not be affected by earth weight distribution and atmosphere so much.
<Joerg-Neo900> I wouldn't want a internet that has a 100,000km single way latency, 200,000 RTT
<Joerg-Neo900> also my landlord would hate me placing an antenna on the roof or just out my window
<houkime> yep, latency is the sad part. We will hit this anyway when internet will go cross solar system tho(
<houkime> for free sth it's ok tho.
<houkime> guess video streaming can also live with it.
<Joerg-Neo900> you know, there already *are* a trainload of sats out there, for Thuraya and Iridium "cellular" phones. They offer "internet"
<Joerg-Neo900> you don't want to use that. Not really
<Joerg-Neo900> Iridium has how many? 98? And still they can't offer anything faintly on par with HSCSD or EDGE
<Joerg-Neo900> heck, a UMTS basestation can't sustain the boldly advertised bandwidth as soon as more than a 100 users are doing data in that cell
<Joerg-Neo900> neither does LTE
<Joerg-Neo900> how would a satellite covering a whole town or country?
<houkime> ok. Your point is here not really about latency but more on how many satellites you need to launch to cover bandwith needed.
<houkime> valid concern
<Joerg-Neo900> actually both. For acceptable latency you need LEO SATs
<Joerg-Neo900> maybe 800km high, like Iridium
<Joerg-Neo900> iirc
<Joerg-Neo900> the lower the orbit, the more sats you need, just to have comprehensive coverage
<Joerg-Neo900> Thuraja uses GEO orbit and only a few sats, size of a grayhound bus
<Joerg-Neo900> beamforming
<Joerg-Neo900> they *could* do a maybe 100000 or a million users, maybe even with acceptable data rate, with better hardway, way better than you could cram into this volume today. but... latency
<Joerg-Neo900> hardware*
<Joerg-Neo900> sorry, spelling error https://en.wikipedia.org/wiki/Thuraya
<houkime> So... if we want to have a free internet with ok latency it might be either atmosat or a network of home wifirouters chatting with each other and forming a net in an anarchical manner.
<Joerg-Neo900> and honestly, when I place a sat dish on my roof for internet, why not point it to a peer (mesh internet) or a land borne base station instead of a satellite?
<Joerg-Neo900> yes, exactly
louisdk has joined #neo900
<houkime> i think wifi is more like a way to go since you don't need extra antennas for it.
<houkime> basically it right now can be a pure software solution
<houkime> at least in some places.
<Joerg-Neo900> https://en.wikipedia.org/wiki/Freenet you still might need dishes
<houkime> I2P also seems like a way to go. However this systems don't cover DIRECT (without ISP) connection between peers.
<houkime> *these
<houkime> so basically what one needs is a soft for routers and smartphones to try establish direct connections between each other.
<Joerg-Neo900> actually sorry, https://en.wikipedia.org/wiki/Freifunk
<Joerg-Neo900> yes, many peer links are simple AP2AP, but some gaps need dishes to bridge them
<houkime> do they use smartphones also?
<Joerg-Neo900> err no, only as WLAN clients
<houkime> Wifi sharing and bluetooth might be ok means and the number of smartphones is HUGE.
<Joerg-Neo900> P2P protocols of all flavors are generally a very poor idea on battery powered embedded devices like smartphones
jonsger has quit [Ping timeout: 265 seconds]
<Joerg-Neo900> might fly in a special situation like a demo, for a few hours. To defeat authorities trying to shut down connectivity of all participants of such a meeting
<Joerg-Neo900> generally it will suck your battery dead in no time, without you even using the device at all
<houkime> recently smartphones are sort of ok with constant connection though.
<Joerg-Neo900> no, they are not
<Joerg-Neo900> WLAN is a 100mW TX and greedy receivers, and nothing will change that#
<Joerg-Neo900> the more data you transfer, the faster your battery is dead
<houkime> though about nfc for a second as about a way to transfer data between phone and router without phone dying out
<houkime> but range probably too small
<houkime> and for a phone to be a relay it needs to be in a range of 2 routers simultaneusly
<houkime> but this will lead to 2 routers being in wifirange from each other so phone is not needed
Pali has quit [Ping timeout: 255 seconds]
<houkime> do green circles display coverage area?
<Joerg-Neo900> green circles are active routers aka APs
<Joerg-Neo900> range is not shown
<Joerg-Neo900> aka coverage
<Joerg-Neo900> since... who could tell
<houkime> looks like the idea is quite popular.
<houkime> strange
<houkime> I asked my sister who uses skyoe all the time on her phone via our wifi
<houkime> *skype
<houkime> she says for 46 minute of video conversation it is only 6 percent of battery or so.
louisdk has quit [Ping timeout: 245 seconds]
<Joerg-Neo900> well, when your sister has a phone that doesn't use 10% of battery even with screen on...
<Joerg-Neo900> for one hour
<Joerg-Neo900> such phones may exist. It's not usual though. Usual is phone getting hot from WLAN constant usage, and where's heat there's much of power getting consumed
<houkime> She also plays MMOs on it) It is some xiaomi mid-range stuff. 250$
<houkime> I mean even if it is not really often now, it quickly becomes ok to have a constant connection.
<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
<Joerg-Neo900> *I*
<Joerg-Neo900> >>The S60 comes loaded with a hefty 3,800mAh battery.<< http://www.trustedreviews.com/reviews/cat-s60-battery-and-conclusion-page-4
<Joerg-Neo900> also
<Joerg-Neo900> ~power
<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.
<houkime> one can calculate this average datarate and see how feasible is this slow-but-frequent network.
<houkime> the thing is that you can send packets different routs to manage the load
<houkime> and if we're speaking about phones, number of nodes and route alternatives can be large.
<Joerg-Neo900> err route alternatives?
<houkime> *alternative routes
<Joerg-Neo900> I think the most important factor is if the WLAN is a client or an AccessPoint aka AdHoc mode
<houkime> when you can connect through A and B but can through C and D
<Joerg-Neo900> I don't see how this applies to a WLAN device
<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
<Joerg-Neo900> obviously in AdHoc and AP mode the device needs to send beacons itself instead
<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
<Joerg-Neo900> funny enough the complex and high bandwidth receiver eats more power than the transmitter
<Joerg-Neo900> and this seems to be valid for all existing WLAN chipsets
<houkime> on phones you can probably do wakeup-calls via cell-related circuitry instead?
<Joerg-Neo900> not when you want to do a peer2peer mesh
<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
<Joerg-Neo900> prolly 5+ days when I shut down IRC
<Joerg-Neo900> 7 if I shut down cell as well
<Joerg-Neo900> not keep an established callof course, just receive an imbound call any time, in standby
<houkime> i want phones to be able to resend packets to other phones but without having to constantly run WLAN receiver.
<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
illwieckz has quit [Quit: Ça va couper chérie…]
<Joerg-Neo900> how would you resend a WLAN data packet to a phone that doesn't constantly run WLAN receiver?
<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
<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.
<Joerg-Neo900> omotate? that's neither possible nor legal
<Joerg-Neo900> imitate*
<Joerg-Neo900> and cell modem employs exactly same deepsleep methods, shutting down the RX for several seconds between very short listening intervals
<Joerg-Neo900> the standby times cranked up from 10h to 5 days when that feature got introduced around 2000 minus a few years
<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
<Joerg-Neo900> so you don't gain anything much by switching from WLAN to GSM_ff
<Joerg-Neo900> plus to imitate a BTS you as well need to constantly send "beacons" (not really beacons) on the cell's service channel
<Joerg-Neo900> the only commonly available low-energy_standby medium-range RF protocol is BLE
<Joerg-Neo900> I don't know how they do it but they manage to run their receivers pretty humble on power consumption
<houkime> thay may use field-powered receivers actually.
<Joerg-Neo900> don't
<houkime> so that each session is initiated with a strong pulse
<Joerg-Neo900> NFC does
<Joerg-Neo900> BLE not
<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
<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.
<Joerg-Neo900> so sleep for 99ms, check 1ms for a well known pattern on a well defined frequency
<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.
<Joerg-Neo900> would require only 100ms of WAKE signaling from the sender, and only a 1% duty cycle of a simple receiver
<houkime> I mean it can be literally sleeping intil brutally poked to action.
<Joerg-Neo900> you can, but signal amplitude drops with almost cube exponent of distance
<Joerg-Neo900> and BT only has max 100mW usually
<houkime> caps
<houkime> can store some power and release as a pulse
<Joerg-Neo900> no
<Joerg-Neo900> theey don't do this
<Joerg-Neo900> it would fail in 3m distance even for a 5W pulse
<Joerg-Neo900> and it would void any hope for getting a certification of the BT transmitter
<Joerg-Neo900> but basically they could do something almost similar, using a pretty passive receiver design for the narrow band receiving
<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
<Joerg-Neo900> 9600*
<houkime> ok, so we might need an open versionof this.
<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
<Joerg-Neo900> TX would send a 100 "!" and each takes 1ms, RX listens for 2ms and can receive one complete char/byte
<Joerg-Neo900> if RX doesn't receive the "!" then it goes to sleep for 98ms again
illwieckz has joined #neo900
<houkime> understood.
<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
<houkime> seems like latency will be a thing again though. Many hops, each is taking minimum 2 ms.
<houkime> in a combined net of routers phones and doishlines might be ok though
<houkime> *dishlines
<Joerg-Neo900> minimum isn't even relevant here. average would be 50ms in this scheme
<Joerg-Neo900> but yu can tune those parameters in a wide range, like 2 or 3 magnitudes
<Joerg-Neo900> and actually a low bandwidth 'passive' receiver might be so humble you could run it 100% duty cycle
<Joerg-Neo900> then you just have the latency from cranking up the high bandwidth RX after you receive a WAKE
<Joerg-Neo900> and I think BT4.0 does something like this with WLAN actually
<Joerg-Neo900> or was it BT5?
<Joerg-Neo900> anyway wake signal on BT, real data communication on WLAN
<Joerg-Neo900> but yes, mesh networks have gigh latencies, that's design immanent
<Joerg-Neo900> high*
<Joerg-Neo900> you already run into this probem when using WLAN repeaters
<Joerg-Neo900> each repeater adds 1 (at least) to the N in 1/N bandwidth of the network
<Joerg-Neo900> so wuth 4 repeaters you get 1/5 of the genuine bandwidth
<Joerg-Neo900> or 1/10
<Joerg-Neo900> since every data package gets transferred no earlier than it been completely received, on a repeater
<Joerg-Neo900> usually
<Joerg-Neo900> *starts getting transferred*
<houkime> soo... protocols need to be dumbed down/redone to support faster hopping?
<houkime> like "don't know what it is will just repeat it it it hits target?"
<houkime> so we have a packet and an antipacket "received" spreading through net
<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
<Joerg-Neo900> some WLAN repeaters use 2.4->5GHz to avoid that problem
<Joerg-Neo900> or vice versa
<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
<Joerg-Neo900> even when you use physically separated antennas that are like 20cm apart from each other
<Joerg-Neo900> s/pacjages/packets/
<Joerg-Neo900> so for all usual scenarios, it's TX and RX are mutually exclusive
<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
<Joerg-Neo900> and you for sure don't want a packet to run in circles through the mesh ad infinitum
<houkime> avalanche+ lifetime counter?
<houkime> -1 every hop
<houkime> though too much stress
<Joerg-Neo900> possible. needs reading of at least the packet preamble with the counter, before you can start retransmitting the decremented counter packet
<Joerg-Neo900> you don't get around the latency per hop
threebar` has quit [Ping timeout: 260 seconds]
<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
<houkime> AAAAAAAAAAAAAPacket, each time one letter gets reduced.
<houkime> then avalanche will produce shorter and shorter packets and no checks are needed
<Joerg-Neo900> go simulate this, with each node havong 5 neighbours, and a node count > 50. You'll pull your hair
<Joerg-Neo900> go send a second and a third packet from different origin nodes concurrently
<Joerg-Neo900> the thing will explode right into your face
<Joerg-Neo900> do you kknow chain letters?
wiewo has quit [Ping timeout: 256 seconds]