AaronD

For a different Debian-derivative (Raspberry Pi; Ubuntu will do this too) that happens to be on 24/7 unattended, I just have a weekly job for when it's idle anyway, that updates and reboots. I don't even have to think about that one anymore.

For a Windoze machine that has a similar job in a different place, I found it impossible to completely disable all of the automatic maintenance so that I can schedule it when it makes sense. So it takes forever to settle down on first start. I did manage, however, to prevent automatic updates specifically, despite not being supposed to be able to do that, by telling it to "not download on metered networks", and then marking ALL of the known networks as "metered". Now it only does that, at least, when I tell it to. It can't be automated like Ubuntu can, so it becomes manual instead.

I don't think it's worth a full answer, but I think it is worth mentioning the way that I maintain a critical live-media machine that runs on Ubuntu: Disabled all of the automatic updates - plumb easy, unlike Windoze which requires some trickery - AND THEN replaced the graphical shutdown command with a script that runs the command-line updater and then shuts down. The reasoning for this specific system is that it's just been told that it's no longer needed, and so this is the best time to do maintenance, instead of mid-show. It also gives the most time to test, for those that are paranoid.

@DKNguyen The system that I have already is simply a transistor in parallel with the button to pull the line down. That works, and I want to keep its functionality, AND add a hold-to-kill function with the same button.

@DKNguyen Scrap the whole idea and just hold the line down directly and indefinitely? Yeah, that would solve this problem...but I already have these buttons (came from the "try me!" packaging for some LED gimmick lights), and I still want a programmatic soft power-off. (actually, that soft power-off works by controlling the MCU_OFF switch that some other gear has already and works, hence my inclusion of it here)

@DKNguyen I guess the direct answer is that there aren't any devices that do exactly what I'm looking for, and it's not trivial to assemble one either, with all of the interactions to keep track of in different configurations. The relay is looking awfully attractive now...

@DKNguyen Later, assuming it didn't latch-up, that same cap and bleeder resistor present a load on the GPIO pullup. A bigger cap needs a stronger bleeder for the same time-constant, and that stronger bleeder counteracts the pullup. Those seem like conflicting goals that need to be balanced. I don't see the purpose of topping off the cap after Q1 converts it to a parasitic load on an ordinary pulled-up button.

@DKNguyen In the process of pulling the enable line low, the cap is charging with ~1.6mA, but there's some delay in the supply actually turning on. That's the time to latch-up. A larger cap makes it less likely for that to happen: same current, same time, less delta_V. The bleeder resistor ensures that it always starts close to 0V instead of something higher that it still has from yesterday.

@DKNguyen Without a bleeder across the cap, sure! But then how do I ensure that I don't latch-up the MCU via the ESD protection during power-on? (V_cap is steadily increasing until Q1 turns on)

@DKNguyen With a bleeder resistor, perhaps, to make sure that the cap is indeed discharged enough to hold the line down while the MCU figures itself out. How then does that work with the GPIO? A big enough cap won't activate the ESD diodes during startup, but it will also slow down the button in "user mode" (hardware debouncing for free). The bleeder resistor might be a bigger problem, in that the GPIO's internal pullup can't bring it up to a logic high, even after infinite time. Disconnecting it when no longer needed, brings us back to the same original problem again.

@DKNguyen According to this, the enable line floats to +5V, and requires 1.6mA to pull down.

@DKNguyen That would be enhancement then. So it would need to float up to some positive voltage and stay there. Are you thinking about using the ATX enable line to do that? It goes away before the FET can be allowed to turn off. A cap and diode might work, but it would require another transistor to isolate that from the GPIO. So now I have 2 transistors for this function (I guess that's okay) and I can only force it into "user-mode", not "direct power mode". To protect the GPIO pin, I guess I could change the held-down-timeout function to wait until the button is released again...

@DKNguyen A P-channel device turns ON with DEcreasing voltage and OFF with INcreasing voltage, which is promising so far, but the current flow that I want to block has a body diode facing the right way to conduct it around the switch...or if I turn it around, then the control voltage is referenced to the wrong signal: GPIO_1 instead of ground. The JFET was an attempt to get away from the body diode...until I learned in my accepted answer to the other question that it's referenced to the average of both terminals.

@DKNguyen With the drain at the higher voltage? That would require an N-channel device, which turns ON with INcreasing voltage and OFF with DEcreasing voltage. Both enhancement- and depletion-mode devices have that polarity; only the offset is different, so that one is OFF at 0V and the other is ON at 0V. And I can't go below 0V!

@jsotola I'm not sure I understand that. The PWR_BTN will not affect GPIO_1 as drawn? Or with PWR_BTN and ??? swapped? (I assume that GPIO_2 still controls ??? even when swapped?) Either way, I think it does affect it, and so the MCU code needs to be aware of the interactions regardless of the arrangement. As drawn, GPIO_1 is held to ground when ??? is on, while the swapped version pulls it up with the ATX enable line. I don't think I like the swapped version just for that reason. Do you see something different?

@jsotola Why should they be swapped? Seems to me like it would work about the same way, with no real benefit or drawback. And yes, I absolutely could use a relay - that'd be the plumb-easy, quick-and-dirty, perfectly-valid way to do it - but I'm curious to see if there's a solid-state way to do it too.

@Jens I'm not seeing that. A PNP with a base pulldown requires power, which I don't have at first startup...and so it won't start up. Unless I'm missing something? (don't want to rely on the ATX's unknown pullup, if that's what you mean...)

@MarkU Those need negative voltage to turn off, if I understand correctly. Just like an N-channel JFET but without the gate diode. I've already looked at P-channel depletion MOSFETs - those take positlve gate voltage to turn off - and while there are a few in a reasonable discrete package, the body diode is backwards for what I need. :-/

@MalteSkoruppa I don't remember doing that. I think I would if I did. Anyway: pastebin.ubuntu.com/p/f36FMfVxdk

I thought that question looked promising, but as you can see from the pastebin, nvidia-prime was already installed. My NVIDIA X Server Settings still doesn't have the PRIME Profiles tab.

@MalteSkoruppa pastebin.ubuntu.com/p/YSpKFcCY6V

@MalteSkoruppa pastebin.ubuntu.com/p/SC2PfqY7Xk

I thought I was using the proprietary driver, but Lubuntu's Additional Drivers says it's manually installed. I must have done something with that at some point, well before it stopped working. cat ./.bash_history | grep nvidia returns one line: sudo apt install nvidia-driver-430

@MalteSkoruppa LiveUSB of Lubuntu 20.04 LTS, downloaded today. /var/log/Xorg.0.log is pastebin.ubuntu.com/p/GDDhPjFTCv xrandr is pastebin.ubuntu.com/p/N3t3JHJ7dh According to LXQt's Monitor settings and the mouse behavior between them, eDP-1 is the internal screen and DP-3 is the external on HDMI. Both work for the live USB as downloaded today and not updated. (didn't even give it the WiFi password)

@MalteSkoruppa pastebin.ubuntu.com/p/M4myb9qkYq (copy/pasted both ways because I really can't see much)

@MalteSkoruppa Oh! I never knew about that, yet somehow I have an account already. I'm pretty sure I never signed up for Ubuntu One either. Anyway: pastebin.ubuntu.com/p/24tSjCHdmW

@MalteSkoruppa Possibly, but even after trimming what I thought was redundant (multiple copies of the same report block with the same info), I still get Body is limited to 30000 characters; you entered 38266. There's a bunch in there about the sleep button, touchscreen, touchpad, etc., so how much is actually relevant? Can I trim that out too to post here?

Normally, I do have a second laptop with the same system installed on it, and SSH already set up to do exactly what you suggest. But I'm away from home for another week or two, and I didn't know to bring it with me.

@MalteSkoruppa Yes, you're right about the wording. Sorry about that. Fixed now. They both happened at the same time though, so I'm pretty sure they're related. I wouldn't be surprised at all if the same solution fixes both.

Personally, I think it's a mistake to start with the math, to require that understanding, and then assume that the intuition is obvious. Most people never get past the math because it's not connected to anything, myself included. But if you start with the intuition, and completely forget the math until the intuition is there, then the same math becomes almost trivial.

You might find this interesting: youtube.com/watch?v=pTn6Ewhb27k (20-minute video)

Upvoted for the rant. That needs to be sticky somewhere.

I think you mean that a capacitor can accept and (more importantly) release energy faster than a battery. The voltage designation is incorrect. It may be charged from a switching power supply that boosts the battery's voltage to then put on the cap, but it's that supply that creates the voltage, not the cap itself.

So it's acceptable to take soaps and shampoos then? I've always wondered that myself.

@CharlesGreen I'm not sure if this tag is really necessary to alert you, but since you did, I figured it can't hurt.

But now that I have the system that I do, I actually kinda like recording to a giant monolithic block and then converting to WAV later. That way I'm not limited by the file size and I know I have it all. If the recorder panics about 6.2 hours into an all-day recording (4GB mono 32-bit WAV file), then there's nothing I can do to get that back. With the monolithic block, at least I know I have it and I can try some other way to get it out.

Demuxing on the fly would be nice! Makes for less work in post. As you can see from the question, I originally wanted that, but couldn't find how to do it. At least not without writing my own like you're contemplating.

Anyway, you're not stuck with USB 01-18 being raw mics 01-16 and final FOH like I have them. You can re-patch all of it, and in fact I do that quite extensively to organize the channel strips for me and the front panel for the stage-setup guy, independently of each other. You can do the same with USB, also independently, and it doesn't have to be raw or final either.

Now the system works as intended and I can capture the live one in front of an audience, as well as the music and whatever else we did, all in multitrack to remix later if someone was so inclined.

The rebooting part bit me on a mission trip as we were packing up to fly home and one of our team wanted to record a testimony with him and our local translator. That was before I had my current system and so I ran the USB directly to the FOH laptop in 2-ch mode (2 mics) and recorded in Audacity. It took a while to figure out why it wasn't working like I thought it should, as we were trying to pack up and catch an international flight.

I don't think you can do that. The setting is for 2/2 (stereo) or 18/18 (multitrack). It also requires rebooting the XR18 before it takes effect.

If you only need 6 channels instead of the full 18, then you could route the first 6 USB Out channels to the signals that you want to capture, then change the arecord command to only capture 6 and the sox command to only convert 6. That'll produce a smaller raw file with consequently longer recording time for the same drive.

Better still, here's the full write-up with source code and everything: forum.music-group.com/…

If I remember right, I think there was too much going on at the time to remember to come back and report success, so that @CL. could make his comment into an answer. Sorry about that.

Wow, I had completely forgotten about this. CL.'s comment to pipe through stdout instead of directly to file was the solution. Basically moves the 2GB problem from arecord to the operating system. So I now produce a single RAW file in the 10's of GB range for each show that I can then split with SoX into a collection of full-length, mono WAV's. Audacity is okay with a 2.5GB WAV, but I haven't tried my system yet with theoretically >4GB per track. I'm sure I could record that long (5.3 hours), but converting might be interesting.

In addition to the other commentary, I'd like to add that the context of use can make a world of difference. For example, in the electronics industry that I come from, a good design for a circuit board can be terrible for a silicon chip and vice-versa because of vastly different component costs. So what may seem like a rube-goldberg solution in one (sub)field might be amazingly elegant in another.

@Brendan: Sometimes, if I can spare the overhead, I'll make a short function like that because I don't know all the details yet. I make a guess, call it everywhere, and in the likely event that my guess was wrong, there's only one place to fix it.

(This is on a non-DSP chip, by the way. Integers only, hardware multiply, no divide instruction. Fixed-point is wonderful once you understand it!)

@jamesqf: Yep, there's that too. Fortunately, the only DSP work that I've had to do so far is to vastly oversample some analog inputs (~4kHz for a 50Hz PID controller), IIR lowpass them, and offer the results as global variables for the rest of the code to pick up as it needs. With a bit of analog noise, this produces several bits better resolution than the ADC can provide directly. I say so far because there's at least one project that's going to need some bandpasses in the near future, and they're not as trivial as a first-order lowpass.

Sure, it'd be a lot easier to use a bigger/faster chip and not worry about it, but when you're designing for mass production, there's a pretty good motivation to cram all you can into the smallest/cheapest fleck of sand that can be made to do the job, even if only barely.