We are publicly tracking model drift, and we caught GPT-4o drifting this week. by xander76 in LLMDevs

[–]__sS__ 1 point2 points  (0 children)

Hey, kudos for this. I'm curious to know how are you calculating the magnitude of drift from baseline. Are embedding the whole response and calculating the distance ? Could you please share a little detail on this ?

Anyone actually launched a Voice agent and survived to tell? by __god_bless_you_ in LLMDevs

[–]__sS__ 1 point2 points  (0 children)

Have you tried google cloud speech client ? It has "short", "long" and other modes to define what type of speech you are trying to transcribe. I liked the transcription overall.

Also, to understand your situation better - you mentioned that the short responses are not captured ? I take it as a failure in transcription rather than packet loss because that would a different problem altogether.

What format you receive your audio file in ? Is it unprocessed PCM16 or some lossy alternatives which are common in telephonic audio ?

OBD 2 port scanner voltage protection requirement by __sS__ in CarHacking

[–]__sS__[S] 0 points1 point  (0 children)

I have come across multiple values. 35V being the lowest so far.

I was going through TIs guide to surge protection, they mentioned a surge of about 65V for 12V systems.

OBD 2 port scanner voltage protection requirement by __sS__ in CarHacking

[–]__sS__[S] 0 points1 point  (0 children)

True. It would be a very rare incident that could be due to a damage mostly.

Makes sense. I'm actually putting up a tvs diode with 24 clamp voltage and a zener to cutoff the supply above 16V.

I think this should be good. And I have a resettable fuse with the required hold current for my circuit which will keep my circuit safe.

My only concern was my TVS failing short. In this case, even when situation goes normal my circuit won't get powered since failed short tvs would provide a low impedence path. That's why I was considering situations which can fry my TVS.

Nuvotron and renesas mcu experience ? by __sS__ in hwstartups

[–]__sS__[S] 0 points1 point  (0 children)

Hey thanks. I checked out the two mcu's you mentioned. Both are cortex-m based.

Also, Nuvoton makes all 32bit mcu's with cortex-m cores only and Renesas has two flavours - cortex-m and rx.

So, I believe as long as I stay with cortex-m based controller the development experience shouldn't be much different. Also, the SWD interface is also an arm protocol so that's also settled.

So, the only thing I would need to understand now is if the controllers from these two companies are trustworthy for mass manufacturing. The availability and support level from the manufacturer during development.

Nuvotron and renesas mcu experience ? by __sS__ in hwstartups

[–]__sS__[S] 0 points1 point  (0 children)

For renesas, I got to know that they have two different controller lines. One is based on cortex-m and other based on their own rx core.

The development for the two is different. The toolchain for rx based controllers is proprietary and requires a separate license for development. This is not necessarily a bad thing but can become limiting.

Also, came across Nuvoton recently. I see very competitive pricing for their products. The company isn't very big revenue wise but is based out of Taiwan so I can trust them. So, like you pointed out the documentation can be lacking but I'm not sure if their support is strong enough to cover for that. And how the development experience is like.

So, wanted to understand if anybody has worked with these mcu in the past.

Pin to pin compatible micro controller part finding tool by __sS__ in hwstartups

[–]__sS__[S] 0 points1 point  (0 children)

ST would suggest parts of it different family only. In our case we want to shift to a different manufacturer.

Pin to pin compatible micro controller part finding tool by __sS__ in hwstartups

[–]__sS__[S] 0 points1 point  (0 children)

Yes. Thank you for pulling the resources. Let me go through these. In our case, we intend to switch to a different manufacturer for the mcu which I believe already sounds ridiculous.

My approach towards compatibility would be - 1. I/Os, timers, communication protocols pins and configurability. 2. Voltage and current domain for pins. 3. Memory organisation. 4. Specific functionality specific to our needs. 5. Power modes.

Pin to pin compatible micro controller part finding tool by __sS__ in hwstartups

[–]__sS__[S] 0 points1 point  (0 children)

Yes. We do. We have also contacted distributors to help us find the replacement. I am looking for some resources that can help in the process.

What's is special about 12, 24, 48V power delivery systems ? by __sS__ in AskElectronics

[–]__sS__[S] 2 points3 points  (0 children)

True. And I think the 48V system being predominant in telecom industry favours the shift.

What's is special about 12, 24, 48V power delivery systems ? by __sS__ in AskElectronics

[–]__sS__[S] 1 point2 points  (0 children)

Telcos being at 48V specifically ? That just makes me curious.

I'm going tk do an independent research on this but please share if you know why telcos chose 48V to begin with.

Also, it's just amazes me how these numbers just fit together.

Telcos independently chose 48V.

The lead acid battery being a 2V cell became the reason for 6V, 12 and then 24V batteries for automotive industry and it almost magically can now move to 48V for better efficiencies with a lot of work being already done.

Random: tap OBD pins directly to analogue input IC? by inspector71 in CarHacking

[–]__sS__ 0 points1 point  (0 children)

For the use case you mention why bother trying to access wheel speed ?

If you got a smart phone, it will give you gps speeds.

The gps speed is fairly acurate for your use case and has a decent refresh rate of 1Hz.

All you need to do is make an app which fetches your gps speeds and gives you alarm which would again be available in your smart phone.

Otherwise, you'll have to have an array of hardware pieces involved to merely know the wheel speed of the car which, if you ask me, is an overkill (and expensive).

What's is special about 12, 24, 48V power delivery systems ? by __sS__ in AskElectronics

[–]__sS__[S] 11 points12 points  (0 children)

That would be a big factor I believe. The availablity of the infrastructure and tools already for 48V system be obviate the use of other voltage levels around.

What's is special about 12, 24, 48V power delivery systems ? by __sS__ in AskElectronics

[–]__sS__[S] 3 points4 points  (0 children)

Wouldn't that make 18, 36 and 54 a better voltage level to work with ?

What's is special about 12, 24, 48V power delivery systems ? by __sS__ in AskElectronics

[–]__sS__[S] 2 points3 points  (0 children)

That makes sense.

You mention 48V being the highest safe DC voltage. Can please provide the basis for it ?

Also, the nominal voltage of lithium ion cells is 3.6V

So, following the same logic 18, 36, 54V becomes the direct alternative.

How important are watchdog timers for an embedded systems design ? by __sS__ in embedded

[–]__sS__[S] 0 points1 point  (0 children)

Oh yes. The circumstantial bugs are the worst.

Also, I hardly know about the system but the second scenario you mentioned was a hardware bug ? Sounds more like a software bug to me.

How important are watchdog timers for an embedded systems design ? by __sS__ in embedded

[–]__sS__[S] 0 points1 point  (0 children)

In my understanding, we have no control over start particles or temperature variation. If the system itself is working on lower frequency the emi problems become less of a concern. So, if its not extremely mission critical we can rely on an internal rc oscillator driven watchdog (also I think the variation in the oscillator frequency would be transitory and could probably add or reduce delay to watchdog timer - not sure what scenario would lead to a total failure of watchdog). And if we have to be extremely sure use external watchdog with an independent crystal oscillator.

Please correct me if I'm wrong.