Fixpoint

2025-05-01

#jwrd Logs for May 2025

Filed under: #jwrd logs, Logs — Jacob Welsh @ 18:20
Day changed to 2025-05-01
[18:20] sstacks: greetings
Day changed to 2025-05-06
[15:07] caai: hello jw: could you remind where the host file is located to change the value of fblserver?
[15:07] caai: tigo went down for about 9 hours and my ip address changed. i thought the setting was in /etc/hosts, /etc/host.conf, /etc/hostname, or /etc/hosts, but i see no configurations in any of those files ....
[15:28] jfw: caai: /etc/hosts would be the global configuration (ie for all applications on the system) but we put it in ~/.ssh/config probably because there were some other settings required there already
[15:37] caai: found it. excellent. danke
Day changed to 2025-05-09
[15:42] jfw: http://jfxpt.com/2025/jwrd-logs-for-Apr-2025/#14501 - panama's been relatively well behaved, just some lesser protests afoot about a minor sounding social [in]security reform
[15:42] sourcerer: 2025-04-29 20:02:46 (#jwrd) whaack: how's Panama? Dorion: it's looking unlikely for me to come in early June. Possibly we could meet in upstate New York / Vermont sometime over the summer, or when you get back to Panama.
[16:05] jfw: http://jfxpt.com/2025/jwrd-logs-for-Apr-2025/#14507 - the republican-gpg effort didn't get off the ground as far as usable results; I suppose it morphed into the FFA project on Stan's table going for (one selection of) ideals, and EuCrypt/VaMP on Diana's bringing for instance http://ossasepia.com/2021/08/08/begin-non-pgp-message/
[16:05] sourcerer: 2025-04-30 07:10:05 (#jwrd) lru: http://trilema.com/2015/the-pgp-w-mode/ - did anyone ever implement this, whether added to gpg, or as a standalone pipe / filter?
[16:08] jfw: looking at the proposal now I'm not sure how the "pass as plain text" would hold up in light of those language models currently running rampant - though I'm not sure I've grasped the larger social/political aims
Day changed to 2025-05-10
[02:44] lru: jfw: yeah, it doesn't look like it would pass the readable text test, just the rough format of it
Day changed to 2025-05-14
[21:02] sstacks: greetings
[21:33] jfw: hey sstacks what's going on?
[21:39] sstacks: Good jfw. Just came back from traveling with family. We were at Republica Dominicana.
[21:40] sstacks: How you been? What's new?
[21:42] jfw: mostly a lot of electronics theory & practice along with preparing the VPS hosting service
[21:42] jfw: life's good
[21:43] jfw: you were having trouble with your EdgeRouter, right? did you still want to bring it over for a look?
[21:46] jfw: I also got some new & rennovated computers in service to consolidate and replace failing ones, which involved some software wrangling; most exciting is I got the Eulora2 client to work on a recent (x)ubuntu
[21:54] sstacks: wow, congratulations for the Eulora2 achievement. Great. When I get my hardware over your place you talk me more about it
[21:55] sstacks: We need to coordinate it. What day and time frame is best for you?
[21:56] jfw: tomorrow's probably not the best but any time Friday is free so far
[21:57] sstacks: What are general thoughts about Bitcoin Core promoting “negotiations” with NFTers and garbage on mempool, eliminating historical filters
[21:58] sstacks: Most probably next week, as this week is very difficult for me as well since im catching up on couple of things. But we could schedule to make it happen
[21:59] jfw: 'bitcoin core' has no credibility around here so I don't spend much time studying their spew, but dunno, what do you think they're up to?
[22:00] jfw: they think ethereum is cool and hope some of it can rub off on them?
[22:01] jfw: how's next wednesday for a visit, then? the new girl nekoluce should be around too
[22:02] sstacks: So it seems they are aligning progressively with shtcoin culture promoting the NFTs and ordinals stuff. They dont want to update spam filters and i think they want to eliminate current ones.
[22:02] sstacks: Great. What time is good?
[22:03] jfw: maybe 11am to spare you the worse afternoon traffic?
[22:04] jfw: fwiw, bitcoind's -minrelaytxfee is about the only spam filter I ever needed there
[22:05] jfw: bring your node too and I can check up on it
[22:06] nekoluce: hello :D
[22:13] sstacks: great bro. perfect time indeed.
[22:13] sstacks: you guys been feeding your blogs?
[22:21] jfw: occasionally at best
[22:24] jfw: sstacks: confirmed for 11am wednesday the 21st, then.
[23:05] sstacks: jfw: Is there's chance it could be at 1130am?
[23:06] jfw: sstacks: sure
[23:07] sstacks: jfw: thx. Ill see you then
[23:07] jfw: great
Day changed to 2025-05-17
[13:34] jfw: dorion: I spent almost all of yesterday reading about voltage regulation & power conversion, covering the basics of linear regulators and just scratching the surface of switching power supplies. the local shop has only the very bare basics from the first category, according to their pdf chip catalog (which nekoluce helped me extract into clean csv)
[13:35] jfw: and not sure yet about the second category, which is what I'd need to create the 12V step-up for high-voltage chip programming
[13:36] jfw: unless I stacked up a ton of AAA batteries or something and used linears.
[13:51] jfw: in a nutshell, linear regulators provide the most "clean" power supply but can only reduce the voltage, and dissipate power in their drive transistor to do it; and unless they're "low dropout" (LDO) they require a few volts of headroom between input and output voltage. switchers are more recent tech, they can produce just about any desired voltage by on/off "pumping" action and smooth out the
[13:51] jfw: output as best they can. this makes them highly efficient and so they're found ~everywhere now, but they produce high-frequency noise (not of the entropic sort, more like a whining or screeching in the ultrasonic)
[13:55] jfw: in this light, I also got better acquainted with the FG's power supply circuitry.
[13:59] jfw: one change I'd try to make, if battery operation is indeed desirable, is to use bigger LDOs because the ones it uses specify a maximum input of 5.5V.
[14:23] jfw: ooh, there *are* off-the-shelf 12V batteries, and my PIC12F6XX seems to specify 10-13V allowed for the programming voltage, so I might get away without further regulation
[14:23] jfw: 23A and 27A for instance
Day changed to 2025-05-18
[16:43] jfw: it even turned out I already had a 23A battery, as surplus from fixing a wireless doorbell. I soldered on leads and it puts out a nice 12.72V.
[16:46] jfw: then I swung back to analog studies with transistor amplifiers, and upgraded my voltage-controlled LED current source to get the lights pulsing to the computer's sound output.
[16:48] jfw: "child's play" at this point but made a fun break from the heavy theory.
Day changed to 2025-05-20
[16:30] sstacks: hey
[16:42] jfw: *waves*
[17:17] sstacks: jfw: just curious, do you have power cords available for hardware im taking? I got mine heavily tubed across my desktop. If you dont i will pull em out np
[17:17] jfw: sstacks: sure, I can provide power cords.
[17:18] sstacks: thanks.. im taking both laptops and the edgerouter
[17:18] sstacks: i might need something else?
[17:19] jfw: maybe trng if you'd like me to check up on its health
[17:35] sstacks: yes, great
Day changed to 2025-05-21
[02:20] sstacks: jfw: Can you send me your address? Maybe email or sms
[19:23] sstacks: thanks jfw!
[21:15] jfw: cheers sstacks. ftr, the upshot was the machines all looked fine, the symptom on the router was that it had been making beeping sounds (I didn't even know it had a beeper), so far one suspicion is a power/wiring/UPS issue but if it happens again I could make a house call
Day changed to 2025-05-25
[23:28] jfw: discovered some obnoxious 'features' of the pl2303 usb-serial breakout adapter: it takes noticeable time to close() - .11s on one system, .27 on another; and for one unit but not another, the first read after open returns a single bogus null/zero byte.
[23:29] jfw: (test: strace cat /dev/ttyUSBx and see that it reads+writes a \0)
[23:31] jfw: happens the same at different baud rates and regardless of whether the receive pin is floating or connected.
[23:40] jfw: but doesn't seem to happen when data is flowing in, as from the FG.
[23:47] jfw: so I guess I'm supposed to treat it as a stateful device, "connect" to it and hold onto the file descriptor long-term. yet because it's USB, the file descriptor can't be relied on long-term, it can throw errors and reset or renumber whenever it feels like
[23:51] jfw: the use case here is writing a daemon to poll a serial-connected sensor.
Day changed to 2025-05-26
[00:00] jfw: ahh, found at least the problem with the \0 in my test setup - need to connect the receive pin to transmit rather than ground, to hold it at +3.3V ie the "inactive" level for UART. probably if the chip sees it starting and held at zero it concludes it's an error of some sort.
[00:01] jfw: though signalling an error by making up a zero data byte is still pretty perverse.
[00:03] jfw: so, I can keep the "stateless" code reopening the device on every poll; the extra delay on close isn't fatal and I'll keep an eye to whether it's spinning the CPU.
[00:12] jfw: http://jfxpt.com/paste/8ceyycaffn - simple profile of where it spends its time, based on polling "head -1 /proc/PID/stack"
Day changed to 2025-05-28
[15:56] jfw: managed to read out the contents of my PIC12, through a $5 locally sourced FTDI adapter board, after designing & building the "extra circuitry" for high-voltage programming which the fpicprog dude wasn't kind enough to describe in his docs.
[15:56] sourcerer: 2025-05-17 14:23:12 (#jwrd) jfw: ooh, there *are* off-the-shelf 12V batteries, and my PIC12F6XX seems to specify 10-13V allowed for the programming voltage, so I might get away without further regulation
[15:58] jfw: the "intel hex" format that fpicprog uses is rather annoying too.
[15:58] jfw: takes a few seconds to read out the ~4k of data
[16:00] jfw: but at any rate, looks like I can bootstrap these things from linux without any vendor-specific magic adapters, drivers or IDEs.
[16:15] jfw: or derpy raspberrypis, out-of-print bus blasters etc.
[16:27] jfw: FTDI and USB dependency is still annoying, and I'm currently doing it from ubuntu toilet box; perhaps if I go further with these I can build a plain serial port based programming dongle. looks like it wouldn't be any slower.
[16:27] jfw: using another PIC, natch.
[23:04] jfw: Now built an improved circuit that adds control of the chip power supply, allowing the "VPP-first entry method" which is more powerful as it can't be blocked by chip-internal configuration. This involved soldering more pin headers onto the FTDI board (with nekoluce joining in the fun), as the included one didn't provide enough signals. Now it sits flat and quite snug on the breadboard, with plenty
[23:04] jfw: of signal lines to play with. Taking advantage of that, I switched to using ones not driven high for the normal serial port/TTY function by the kernel driver (ftdi_sio etc), so the +12V and other signals aren't pushed onto the chip prematurely even if the usbserial stack is loaded.
[23:05] jfw: it works at 3.3V and 5V too; the first version didn't seem to work at 5. still not quite sure why, maybe just flaky breadboard connections, or the new circuit is just sufficiently improved.
[23:08] jfw: 10 resistors and 4 transistors, in NPN-PNP switching pairs. bipolar transistors might not be the best choice for the job, but I haven't dug into FETs yet, so thus far I have a hammer and everything looks like a nail, plus it's been good design practice.
[23:10] jfw: since the programmer is probably something worth keeping around, a next prototyping step could be to get a socket for the PIC chips and solder it all down on perfboard, something I don't have any practice with yet.
Day changed to 2025-05-31
[15:47] jfw: http://jfxpt.com/2025/jwrd-logs-for-May-2025/#14578 - the spurious nulls proved a problem in practice for my application (isolated mains power supply monitoring), so I changed the code to maintain a persistent file descriptor after all, but at least attempt to reopen on I/O errors.
[15:47] sourcerer: 2025-05-26 00:00:40 (#jwrd) jfw: ahh, found at least the problem with the \\0 in my test setup - need to connect the receive pin to transmit rather than ground, to hold it at +3.3V ie the "inactive" level for UART. probably if the chip sees it starting and held at zero it concludes it's an error of some sort.

No Comments »

No comments yet.

RSS feed for comments on this post. TrackBack URL

Leave a comment

Powered by MP-WP. Copyright Jacob Welsh.