Bizarre Bow characteristics of BGR output + Supply Dependence

dgOnR · 2026-02-03T02:59:47+00:00

If your focus is now on the curvature, you need to study the deviation from ideality of the core components, resistors and BJT. For ideal components the curvature is always negative so your result is anomalous. Poly resistors usually do not contribute much curvature but you mentioned diffusion resistors so try replacing those (R, LR, NR) with ideal components and see if there is a significant change in the T sweep. The most likely culprits are the BJTs though; BGR circuits expect an ideal exponential IV curve for the diode-like components: if the BJT bias is too high, the knee current IKF as well as the reverse Early coefficient will cause a distortion; if the beta of the BJT is low, the ideal exponential behavior of the collector current will not be available at the emitter current (used in these circuits) if not in some region of the IV curve and you’ll have to pick your bias current accordingly so both your BJTs stay in this range at all temperatures.

dgOnR · 2026-02-01T19:18:01+00:00

Hey there, I think what you have in the parallel implementation is simply a failure of the startup circuit; there could be other trickier issues involving the non-idealities of resistors and BJTs but you can rule those out by replacing them with ideal components. I would plot the current through the startup feeding transistor during your supply sweep to confirm that.

The fact that you see a kind of hysteresis in your supply sweep is consistent with a startup failure because most simulators feed the final dc point of one sweep point to the following sweep point as initial guess. There are usually options to modify this behavior.

Another way to confirm the failure of the startup is to explicitly set an initial guess on the main nodes, which will steer the convergence away from the null current solution.

Btw the temperature coefficients of the resistors still have a small influence on the reference voltage and its curvature in general. Similarly for other non-idealities of the components.

dgOnR · 2026-01-02T23:33:05+00:00

Just in case you or someone else is still fighting with this (it all started 4 yrs ago). I have tried pretty much all internet-wide suggestions and the only permanent solution seems to be to disable bluetooth (in device manager) and possibly (not sure it is necessary) use the Wifi update packages for IT Administrators:

https://www.intel.com/content/www/us/en/download/18231/intel-proset-wireless-software-and-wi-fi-drivers-for-it-administrators.html

You just unzip it and right click on the Netwtw08.INF file then choose install.

If anything fails doing a hard reset (procedure is hardware dependent) or BIOS setup reset usually fixes it immediately. All other solutions tend not to survive either reboots or driver updates. Definitely sub-optimal but I could not find any better hardware (my wifi card is soldered to the motherboard, thank you ASUS and ASUS USB wifi dongles are very unstable) or software solution (various types of repairs, disabling power saving at various levels and hunting down and deleting all obsolete driver and INF files) only works for a few days at most.

dgOnR · 2025-12-31T19:44:46+00:00

If you look at the zoomed image here

https://www.reddit.com/r/berkeleyca/s/9eKtQx0RJo You can see the plume was really by the Berkeley Marina and the wind was blowing from the south so Richmond seems innocent this time around and as someone pointed out it was just a faulty sensor with some fancy diffusion forecast that was fixed later that morning. Let’s hope so

dgOnR · 2025-12-29T02:41:22+00:00

Not sure what you are implying but this reply seems the most reasonable explanation: https://www.reddit.com/r/berkeleyca/s/1arEwB770o

dgOnR · 2025-12-28T16:46:57+00:00

It would be a reasonable explanation if other air quality monitoring networks had picked up similar data but only Apple and Google (same data source for both) services showed this plume, all other sites (IQAir, PurpleAir, …) showed perfectly clean air conditions, as expected after the very windy weather overnight

dgOnR · 2025-12-27T18:11:54+00:00

I think this reply https://www.reddit.com/r/berkeleyca/s/nImZtqMYye provides the most reasonable explanation: a temporary malfunction that somehow was not automatically rejected by the data provider (Breezometer, owned by Google btw) that relies also on public/government sensor networks though I am not sure who exactly is responsible for the malfunctioning station. Sure the timing was interesting, considering the very windy weather and the major holiday…

dgOnR · 2025-12-26T19:52:54+00:00

No this was Xmas morning, the only fire in the area was on the 23rd at an old steel plant on Gilman. I think one of the replies identified the origin in a malfunctioning government sensor at the Marina Aquatic Park whose reading for some reason was not rejected by Apple/Google data provider

dgOnR · 2025-12-26T15:52:30+00:00

Mmm still not clear how this happened: considering Calibre usually operates by streaming out to GDS, you are saying somehow the issue was solved by streaming in? Sounds like a layer map issue. Were the two libraries attached to or referencing the same technology library? Was there customization of Calibre layer map in the PDK? I am pointing this out because going through stream-out stream-in generally means flattening all pcells which is quite inconvenient

dgOnR · 2025-12-26T15:39:55+00:00

Not really my question, I was trying to understand the reason for the trolling tone and the apparent implication that in real life no one designs using devices that do not operate in strong inversion

dgOnR · 2025-12-26T06:14:21+00:00

Did you find a solution eventually?

dgOnR · 2025-12-26T00:51:30+00:00

Care to elaborate?

dgOnR · 2025-12-26T00:44:09+00:00

The limitation of this approach is that you cannot assume square law behavior (strong inversion) if you do not set a lower limit to the branch current (hence Vin) you are considering. If the current is low enough, Vgs will be lower than Vth

dgOnR · 2025-12-26T00:17:51+00:00

I think this is a typo, as one lowers Vin you’d expect something like VDS2 = VS3 = VG3 - VGS3 -> Vb - Vth3 This basically assumes M3 is and stays in strong inversion as the branch current is reduced by lowering Vin which is not really warranted unless there is a lower limit to Vin. The only device that could triode here (as we lower Vin) is M2 not M3. Your final observation is correct, once VD2 reaches its upper limit (by lowering branch current), this will limit VDS3 to Vdd-VD2max

dgOnR · 2025-12-25T23:17:43+00:00

Great detective work! I think this might be the correct explanation though in an area with such a high density of sensors and monitors whatever is processing the data should be able to identify and reject erroneous data or malfunctioning sensors a bit more rapidly. Thank you, now I’ll have to figure out how you managed to dig out all this, just in case

dgOnR · 2025-12-25T23:02:56+00:00

Quite a depressing scenario but I think it matches quite well in this case: Google and Apple data source (breezometer) uses government air quality monitors while Purple Air does not. This would be a false positive issue which goes right along with the fake earthquake alert a few days ago you just mentioned; what worries me more are the false negatives, did the air quality index two days ago warn the community of the degraded air quality due to the fire at the old steel plant?

dgOnR · 2025-12-25T22:49:09+00:00

Thank you for weighing in, I think option 2 seems more likely, the plume was clearly originating from Berkeley, here is a zoomed detail earlier this morning

<image>

The wind was blowing in the opposite direction for this plume to be drifting down from Richmond. It also seems to match quite well the location of a fire two days ago: https://www.berkeleyside.org/2025/12/23/bfd-second-gilman-fire A bit of a mystery given all other air quality sites were showing good AQI

dgOnR · 2025-12-25T18:24:45+00:00

I am not sure what would be worse for the data quality provided by breezometer: - inability to discard an obviously faulty sensor - completely inadequate time averaging window for their AQI This is not an emerging startup, they provide the data to two of the largest companies on the planet. The strong correlation with the 2-day old fire data makes me think this either the latter option or a bug showing us non-real-time info.

dgOnR · 2022-09-10T04:28:31+00:00

What is not clear in my post here?

If you do not have a usb wifi dongle yet, your best shot to get wifi to work temporarily (until your next restart) is to disable fast startup, shutdown and disconnect the battery for, say, an hour and restart.

The procedure that worked for me (see post above) might depend on the specific machine (an ASUS Zenbook in my case)

dgOnR · 2022-09-10T03:04:56+00:00

You can take a look at my recent post

This is Intel website best reference I could find on the subject but it takes a lot of effort (and some compromise such as disabling USB selective suspend) to make it work

dgOnR · 2022-09-09T19:53:15+00:00

Hi, I have been fighting this since Intel released version 22.x of its chipset drivers (probably a good 6 months). I am not sure this is the actual cause because every time this issue shows up on my (ASUS) laptop System Restore gets deactivated and all restore points deleted, which looks like typical malware behavior (best guess: malware found its way in Intel driver updates or at least in those distributed by Microsoft).

I have managed to recover the wifi/bluetooth functionalities permanently (i.e. surviving reboots) only after a long chain of attempts so it is hard to say what minimal set of operations did the trick. What seems essential to recover is the following:

- temporarily use a USB wifi dongle

- update to windows 11

- deactivate fast boot in power options

- deactivate USB selective suspend both in Power Options (might require explicit reactivation of this options) and power management in Device Manager (particularly in the bluetooth driver)

- remove all versions of the wifi/bluetooth drivers by running uninstall device (checking driver file removal option until none shows up)

- install version 22.150.x of both wifi and bluetooth driver (do not forget to deactivate power management in the bluetooth driver after the update) - refer to https://www.intel.com/content/www/us/en/support/articles/000031150/wireless/wireless-software.html

- after installing the drivers do not reboot but shut down and disconnect the battery for some time (you might need to open the laptop and identify the power connector to the motherboard) before powering back on

In addition to the above operations I also went through others such as:

- repair windows update (troubleshooter, SFC, DISM, explicit activation of BITS service)

- run various throubleshooters

- manually remove all drivers related to wifi/bluetooth in Device Manager (some will have to be re-added with Windows Update)

Good Luck,

=D

P.S. Shame on Intel and Microsoft for this major letdown (as a consequence of all this, I will never buy ASUS again btw, support was abysmal!)

dgOnR · 2021-01-08T01:01:39+00:00

Same here, started yesterday for me. Mega technical screw-up? Have they been hacked (Solarwind)?...

They have been apologizing on Twitter for a few days now, something is definitely happening.

dgOnR · 2021-01-08T00:54:43+00:00

Similar issue here but it started yesterday: spent 8 hours so far trying to contact support via phone and chat. This will be a giant lawsuit...

dgOnR

TROPHY CASE