2022-08-15.log

- sl (QUIT: Quit: leaving) (~sl@104-59-85-219.lightspeed.iplsin.sbcglobal.net)00:16
+ sl (~sl@104-59-85-219.lightspeed.iplsin.sbcglobal.net)00:21
- chomwitt (QUIT: Ping timeout: 268 seconds) (~chomwitt@2a02:587:dc15:5e00:4394:5e3a:258b:d8da)00:49
- MajorBiscuit (QUIT: Ping timeout: 268 seconds) (~MajorBisc@46-229-126.internethome.cytanet.com.cy)01:26
kitty4XMPP is really great but its not really for what IRC does01:31
kitty4XMPP is amazing for smaller in-groups and PMs, compared to IRC which is great for quickly joining large topic specific chats01:31
kitty4kfx: I have not had that experience at all with XMPP, I have seen nothing but good from it.01:32
- mtm- (QUIT: Ping timeout: 268 seconds) (~mtm@c-73-27-62-116.hsd1.fl.comcast.net)02:04
kfxmy experience with xmpp was mostly from having to administer servers.  never again02:25
+ bkeys (~Thunderbi@static-198-54-135-69.cust.tzulo.com)03:25
+ mtm (~mtm@c-73-27-62-116.hsd1.fl.comcast.net)04:09
- vagrantc (QUIT: Quit: leaving) (~vagrant@2600:3c01:e000:21:7:77:0:20)06:19
jackhillhttps://biboumi.louiz.org/ is actually a realy great IRC transport for XMPP. As I understand it, bridging to other protocols was part of XMPP's design space. I only use biboumi for a few channels, becasue I already had an existing IRC set up, but if you're already using XMPP for some stuff it makes total sense to me.06:57
jackhillSome nice things with biboumi are good client support on mobile, and you get multiple device and persisten connection (i.e. bouncer functionality for free).06:58
jackhillCurrently, I'm using XMPP for native XMPP, a little bit of IRC, and PSTN networks. I found bifrost for XMPP <-> Matrix bridging to be less pleasurable to use, but I think that plugs more into the matrix side of things than xmpp, which could explain the friction.07:00
jackhillBoostisbetter: ^^ XMPP is my platform of choice :)07:00
- svp (QUIT: *.net *.split) (sid537750@id-537750.uxbridge.irccloud.com)07:02
- kklimonda (QUIT: *.net *.split) (sid72883@user/kklimonda)07:02
- joeyh (QUIT: *.net *.split) (joeyh@kitenet.net)07:02
- V (QUIT: *.net *.split) (~v@ircpuzzles/2022/april/winner/V)07:02
+ joeyh (joeyh@2600:3c03::f03c:91ff:fe73:b0d2)07:02
+ V (~v@ircpuzzles/2022/april/winner/V)07:02
+ svp (sid537750@id-537750.uxbridge.irccloud.com)07:02
+ kklimonda (sid72883@user/kklimonda)07:02
- piroko (QUIT: *.net *.split) (~piroko@104.225.216.16)07:17
- C-Keen (QUIT: *.net *.split) (cckeen@pestilenz.org)07:17
+ C-Keen (cckeen@pestilenz.org)07:17
+ piroko (~piroko@104.225.216.16)07:17
+ MajorBiscuit (~MajorBisc@c-001-021-007.client.tudelft.eduvpn.nl)07:21
sknebeljackhill: PSTN?  SMS or also calls?07:33
kitty4jackhill: everything involving matrix is less pleasurable than other comparable standards tbh lmao07:38
- chartreuse (QUIT: Ping timeout: 268 seconds) (~chartreus@node-1w7jr9ql2247ulxzt91eckjma.ipv6.telus.net)07:52
jackhillsknebel: both. I rent a phone number from jmp.chat and use it with the related cheogram.com transport. They're very FLOSS friendly.07:53
jackhillkitty4: lol!07:53
- Ar|stote|is (QUIT: Ping timeout: 268 seconds) (~linx@149-210-4-98.mobile.nym.cosmote.net)08:48
+ chomwitt (~chomwitt@2a02:587:dc15:5e00:1cf8:31f1:edb9:8492)10:03
+ rah (rah@verain.settrans.net)10:46
rahthe description for https://source.mnt.re/reform/reform-boundary-uboot says "The goal is to migrate to mainstream u-boot or barebox ASAP. The main impediment so far is the 4GB RAM config."; is that still the case or is the Reform supported by mainline now?11:00
minuterah: there has been mainline support in barebox for a longer time but we didn't migrate to it12:02
minuterah: there were some efforts to get to mainline in u-boot but it was problematic, bluerise tried it a few times12:02
rahminute: what was the problem with u-boot?12:05
rahwhen you say "migrate", do you mean migrate MNT's system images?12:05
- Nulo (QUIT: Ping timeout: 268 seconds) (~Nulo@user/nulo)12:08
minuterah: i think patches were not picked up12:09
minuterah: https://lists.denx.de/pipermail/u-boot/2021-December/469589.html12:10
minuterah: https://lore.kernel.org/all/20220112220006.GE9207@bill-the-cat/T/12:10
minute> > is there anything I can do to help get attention on this patchset?12:11
minute>12:11
minute> Not a whole lot, sorry.  The big hold up right now is that Stefano is12:11
minute> out currently and that means a number of imx patches are still12:11
minute> outstanding.12:11
minuteThis is a new CONFIG_, and they should be handled by Kconfig - I get an 12:11
minuteerror after applying the patch. Please move to Kconfig or rework, thanks !12:11
minuteBest regards,12:11
minuteStefano12:11
minuteah, this was then not followed up with.12:12
minuterah: if you have experience with u-boot, if you can, you could pick up there and post a v512:13
minutei think the original author (bluerise) lost motivation because it took so long12:13
rahlooks like there is a v5: https://lore.kernel.org/all/YrjS3ufBgYf7v4yb@ryzen.fritz.box/T/#mb5f03168363641e652c9010486f5877c7827b13612:17
rahso it's in progress it seems12:17
minuterah: oh sorry, cool, i didn't catch that12:18
- buckket (QUIT: Read error: Connection reset by peer) (~buckket@pdp8.buckket.org)12:24
+ buckket (~buckket@pdp8.buckket.org)12:27
- GNUmoon2 (QUIT: Remote host closed the connection) (~GNUmoon@gateway/tor-sasl/gnumoon)14:02
- mtm (QUIT: Ping timeout: 268 seconds) (~mtm@c-73-27-62-116.hsd1.fl.comcast.net)14:04
+ GNUmoon2 (~GNUmoon@gateway/tor-sasl/gnumoon)14:19
+ Nulo (~Nulo@user/nulo)14:20
+ mjw (~mark@178.224.72.45)14:29
+ mtm (~mtm@c-73-27-62-116.hsd1.fl.comcast.net)16:09
- GNUmoon2 (QUIT: Remote host closed the connection) (~GNUmoon@gateway/tor-sasl/gnumoon)16:10
+ GNUmoon2 (~GNUmoon@gateway/tor-sasl/gnumoon)16:11
+ cinap_lenrek (~cinap_len@ns3076381.ip-147-135-136.eu)16:47
cinap_lenrekordered new cells anre safely removed the old cells from my reform16:49
cinap_lenrekand measured then in multimeter16:49
cinap_lenreksome measure 0.65, some 2.5... and some even seemed to have reversed polarity and now measure -0.1116:50
cinap_lenrekis it possible to recover the cells comehow?16:51
cinap_lenrekshould i send them somewhere for recycling?16:52
minutecinap_lenrek: you can throw them in the battery bin in a supermarket17:07
cinap_lenrekokay17:07
minutecinap_lenrek: if they're above 2V they should be fine17:08
* Kooda2 -> Kooda17:09
cinap_lenrekok17:10
cinap_lenrekminute: i asked before what is a reliable way to check if we'r powered from the brarrel jack....17:11
cinap_lenreki'd like to keep my power-on-sam hack, but just avoid powering on when on battery only17:12
cinap_lenreksorry17:12
cinap_lenrekpower-on-som17:12
minutecinap_lenrek: the number of missing cells is a good indicator i guess17:12
cinap_lenreki saw this17:12
cinap_lenrekif (volts < WALLPOWER_DETECT_VOLTAGE && .... )17:13
minutecinap_lenrek: i'm not 100% sure if wallpower detect is reliable17:13
cinap_lenrekokay17:13
minutecinap_lenrek: but if missing cell count is 8, you have no cells17:13
cinap_lenrekyeah17:13
+ chartreuse (~chartreus@node-1w7jr9ql2247ulxzt91eckjma.ipv6.telus.net)17:14
cinap_lenrekso, best place is in if(state == ST_MISSING && cycles_in_state > 5 && num_missing_cells == 8)17:17
cinap_lenrekand then just power up once17:17
cinap_lenrekso this also means if theres any missing cells, we'll stop charging17:19
cinap_lenrekinteresting17:19
cinap_lenrekand also stop balancing/discharging17:19
cinap_lenrekand it will remain in missing state17:19
cinap_lenrekmakes sense17:20
+ vagrantc (~vagrant@2600:3c01:e000:21:7:77:0:20)17:20
minutecinap_lenrek: yep17:22
- Nulo (QUIT: Remote host closed the connection) (~Nulo@user/nulo)17:23
+ Nulo (~Nulo@user/nulo)17:23
- GNUmoon2 (QUIT: Remote host closed the connection) (~GNUmoon@gateway/tor-sasl/gnumoon)17:26
+ GNUmoon2 (~GNUmoon@gateway/tor-sasl/gnumoon)17:27
- mjw (QUIT: Ping timeout: 252 seconds) (~mark@178.224.72.45)17:37
+ mjw (~mark@178.226.74.65)17:43
+ dario_ (~dario@2001:9e8:3651:4dfc:c48a:add4:9e2c:e839)17:47
- mjw (QUIT: Ping timeout: 248 seconds) (~mark@178.226.74.65)17:48
- dario_ (QUIT: Quit: Leaving) (~dario@2001:9e8:3651:4dfc:c48a:add4:9e2c:e839)18:00
+ mjw (~mark@178.226.219.83)18:08
cinap_lenrekhmmm18:22
cinap_lenrekminute: in the oled display, when all cells have been removed18:23
cinap_lenrekit says "cells missing:6,....."18:23
cinap_lenrekshouldnt that be cells missing:8?18:23
- chomwitt (QUIT: Ping timeout: 255 seconds) (~chomwitt@2a02:587:dc15:5e00:1cf8:31f1:edb9:8492)18:31
- qbit (QUIT: Quit: WeeChat 3.5) (~qbit@h.suah.dev)18:33
+ qbit (~qbit@h.suah.dev)18:36
cinap_lenrekah18:36
cinap_lenreki see18:36
cinap_lenrekif i unplug wall and replug18:37
cinap_lenreki sometimes get 5 or 7 missing cells18:37
cinap_lenrekthis is just the number of cells when it decided to go into missing state18:37
cinap_lenrekand it will just stay in missing until number of cells missing cells reaches 0 again18:37
+ Major_Biscuit (~MajorBisc@46-229-126.internethome.cytanet.com.cy)18:48
- MajorBiscuit (QUIT: Ping timeout: 268 seconds) (~MajorBisc@c-001-021-007.client.tudelft.eduvpn.nl)18:51
- mjw (QUIT: Ping timeout: 252 seconds) (~mark@178.226.219.83)19:05
+ chomwitt (~chomwitt@2a02:587:dc15:5e00:ece7:3fb3:7c32:eccf)19:16
cinap_lenrekyep19:20
cinap_lenrekworks19:20
cinap_lenrekso it eventually detects all missing cells19:21
cinap_lenreki'm printing now missing_bits in the status string as hex19:21
cinap_lenrekminute: and you'r right. the volts doesnt seem to get over WALLPOWER_DETECT19:30
Boostisbetterso not to sideline the convo, but sigrid: I think xmpp is better than IRC for a few reasons, but for large group chats, I can see IRC being superior for many reasons as well. 19:37
BoostisbetterI use XMPP for IRC because it is easier for persistence using a bridge, and because then I can just use one client instead of needing a specific IRC client. 19:37
BoostisbetterIn fact, the only IRC channel I am even in, is this one. 19:37
+ mjw (~mark@178.226.219.83)19:47
- cinap_lenrek (QUIT: Ping timeout: 256 seconds) (~cinap_len@ns3076381.ip-147-135-136.eu)19:53
+ cinap_lenrek (~cinap_len@ns3076381.ip-147-135-136.eu)20:03
cinap_lenrekminute: i think i found a bug20:03
cinap_lenrekminute: the ST_UNDERVOLTED state has a deep_sleep_seconds()20:03
cinap_lenrekminute: after the reset_discharge_bits();20:04
cinap_lenrekbut reset_discharge_bits() doesnt work immediately20:04
cinap_lenrekall it does is to set the discharge bits for the next cycle20:04
cinap_lenrekand its also not really a state20:04
cinap_lenrekas soon as we enter it, we'd go directly back to ST_CHARGE state20:04
cinap_lenreki guess it doesnt matter as we only enter undervolted from ST_CHAGE, which already clears the discharge bits20:06
cinap_lenrekwouldnt it make more sense to just set next_state = ST_POWERSAVE from ST_UNDERVOLTED?20:08
cinap_lenrekand remove the deep_sleep_seconds() call?20:09
minutecinap_lenrek: interesting, thanks20:43
minutecinap_lenrek: i wish you had a source.mnt.re account and could make a MR ;)20:44
- mjw (QUIT: Read error: Connection reset by peer) (~mark@178.226.219.83)20:46
cinap_lenreki will eventually20:48
minutecinap_lenrek: nice20:54
minuteupdated system image is built cc josch https://source.mnt.re/reform/reform-system-image/-/jobs/868/artifacts/browse/reform2-imx8mq/20:54
+ erle (~erle@ip5f5af7a8.dynamic.kabel-deutschland.de)21:34
cinap_lenrekminute: are the cycles_in_state delays justified somewhere?21:37
cinap_lenreki noticed we'r essentially spinning for 5 seconds in ST_CHARGE state before transitioning to ST_MISSING21:38
cinap_lenrekor ST_UNDERVOLT21:38
cinap_lenrekat best, we'r going to do a POWERSAVE cycle, but only for 1 second21:39
minutecinap_lenrek: they're not optimized in all cases, i paid more attention to the timing in the balancing, cooldown etc states21:39
cinap_lenrekin fact21:39
minutecinap_lenrek: so you can probably shorten some stuff21:39
cinap_lenrekwhile we'r spinning there waiting for the cycles to reach the condition21:40
cinap_lenrekwe could potentially only transition to a ST_OVERVOLT21:40
cinap_lenrekbut that is predicated on a 2 second timeout as well21:40
cinap_lenrekthe only thing thats not predicated is the transition to POWERSAVE :D21:40
minutecinap_lenrek: feel free to tighten up the stuff21:40
cinap_lenrekwell, its predicated on the holdoff time21:40
cinap_lenrekwhich is ironic :D21:40
cinap_lenrekbut yeah, you want to still poll the uart21:41
minuteyou're probably the first person after me to think about this stuff in detail at all21:41
cinap_lenrekthats mostly the reason for this i think21:41
cinap_lenrekminute: the powersave stuff was added later, no?21:42
cinap_lenrekminute: it is not a critique21:43
minuteyep, mostly by chartreuse iirc21:44
minutecinap_lenrek: yeah no, i appreciate you looking into this21:44
+ mjw (~mark@178.226.219.83)21:59
cinap_lenrekminute: does enable_charge_current()/disable_charge_current() affect the voltage measurements on the cells?22:30
minutecinap_lenrek: not sure. probably 22:31
cinap_lenrekbut so does the som, discharging it22:33
cinap_lenrek(i guess)22:34
cinap_lenrekman22:34
cinap_lenreki need to study this22:34
minutewell, that's true.22:35
minuteand also the balancing.22:35
cinap_lenrekindeed22:35
+ ajr (~ajr@user/ajr)22:43
cinap_lenrekdischarge is disabled during measurement by the chip22:44
chartreuseMeep23:18
chartreuseI really only did the powersave part of the keyboard circuit, and even that's been changed now23:19
chartreuseEr, the code for doing the keyboard powersave 23:24
chartreuseThough I imagine that code is different now since IIRC new versions are using a different microcontroller?23:25
minutechartreuse: well the reform kbd with rp2040 is not done yet. i have the pocket one, but it doesn't have powersave yet.23:57

Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!