Recent Posts

Pages: [1] 2 3 4 5 6 ... 10 Next
Microcontrollers & FPGAs / Re: Small Form factor FPGA/CPLD chip
« Last post by Berni on Today at 04:10:34 pm »

Caution, ZE parts are 1.2V. You may mean 1200HC, though they don't come in the 0.4mm BGA package.

Ah yeah forgot that Lattice gotcha. FPGAs in general tend to have a lot of hidden quirks to watch out for. But with lattice you generally don't want to use the small BGA chips anyway because they are a living hell to make a PCB for (Microvias or via in pad costs a damn fortune to manufacture without massive volumes) You probably want the QFN packages if you are going for size and don't already have a fancy high density PCB already. At lattice all the big pitch BGAs are also high pin count so they are just as big as the TQFP ones.
Metrology / Re: Couple Questions about Reference Divider
« Last post by Crossphased on Today at 04:10:25 pm »
Stray capacitance perhaps from the flying capacitor?
One of the differences between your cirquit is that your flying capacitor is much larger than my WIMA MKS 02 (2.5 mm raster) 1uF.
Perhaps your capacitor has a "outer foil" which is on the wrong pin.
So I would try first to swap the pins of the capacitor and then try a smaller one.

I usually handle such things in software (EEPROM coefficient).

For a fixed 5V reference out of 10V I would do a overall adjustment
of the 10V Reference (at the trim pin) in a way that the 5V fit.

with best regards


Edit: did you measure the frequency of the LTC1043?
You should have something around 400-500 Hz.

Thanks for the helpful tips. I disconnected the shield lead from pin 10, but no change. Next I shall switch capacitor leads and then reconnect the shield lead.

I hadn't measured the frequency before, good idea! I just measured it and here is result:

Only 250 Hz. Maybe this is the problem? When I built this circuit I know put the correct capacitor value in for oscillation pin, but I will unsolder it and measure to verify.

Is there any way to measure parasitic capacitance? Thanks very much for all the help.
Beginners / Re: Parts organization
« Last post by TERRA Operative on Today at 04:06:53 pm »
For electrolytic capacitors, I use the drawers as shown above.
My sorting method is on three axis as follows.
Horizontal: 1uf, 10uf, 100uf, 1000uf, 10000uf etc.
Vertical: Increasing standard values, ie. 10uf, 22uf, 33uf, 47uf etc.
Then each drawer is organised low to high voltage rating, front to back.

Works well and keeps things logical.
Beginners / Re: Reduce inrush current LTspice simulation
« Last post by rakeshm55 on Today at 04:01:30 pm »
Can I add in some series resistance (say 10Ohms) during initial turn on??

Then once the Capacitors charge to a certain voltage level say 20-22V (Use TL431) I bypass using a pmos...

On googling i could not find any literature or standard technique on this --- I have seen delayed turn on but not voltage sense based Any inherent drawbacks for this??

What should be wattage needed for  resistor?? say I use a 10 Ohms 0.125W resistor. 100ms An  average current of 1A flows. Will the resistor sustain shuch pulse loads??
Beginners / Re: What did I miscalculated ??
« Last post by boB on Today at 03:52:26 pm »
Well, not sure what you're expecting exactly but looks like the DC voltage output of the op amp is approximately correct.

Gain should be approximately 15 with 70K/5K + 1 and 0.193V DC in and 2.9V DC output.

AC component is almost nothing so the frequencies around 12 kHz are probably meaningless here.

Renewable Energy / Re: When Will Electric Cars Become Mainstream?
« Last post by mtdoc on Today at 03:49:26 pm »
It appears that despite all of Musks shenanigans and all the Musk hater, TSLA short seller gyrations, the model 3 is a hit and production has ramped up impressively. Tesla is smoking the competition and even some of the large short sellers are changing their position.

It remains to be seen if this will be too late in coming to save Tesla as an independent company but it is an impressive feat IMO given the forces aligned against them. I suspect a bigger problem is about to emerge for not only Tesla but all auto makers. Auto sales are collapsing in mass and the global economic Ponzi scheme is on the cusp of implosion.  Interesting times.

General Chat / Re: Apple & Customs STOLE Louis Rossmann batteries
« Last post by wraper on Today at 03:48:53 pm »
Believe what you want, ok? I’ve spent my entire career in the computer industry in one way or another, so I know what happens in the field.
Dunno what you were doing in your computer industry career but based on my past experience working as a warranty repair technician, I can say you have no clue what you are talking about.
I thought it would be more optimal, and easier to have a circular buffer with read pointer always following the write pointer by pre_trigger (of course a little more than pre_trigger to account for latency) and when trigger, have a down counter activate the read and write for the transfer from one FIFO to another.

If the latency is the same for all kinds of triggers you certainly can do this. Or, you can build all your triggers so that the latency is always the same. This way, you may not even need memory. You can use shift registers - ADC writes, then n cycles later you read it from the other end. It depends on how long the pre_trigger is.
Beginners / Re: What did I miscalculated ??
« Last post by MarkF on Today at 03:42:41 pm »
The OP07 op-amp is not single supply.  You will not be able to get that close to the negative rail (ground in your case).  The input voltage range would need to be a couple volts away from the power rails.  While the MC34071 is single supply.

Your circuit needs a single supply or rail-to-rail op-amp to work correctly.  Give the OP07 a negative voltage and test it again.
The vulnerability of TCP/IP stacks to attacks, including buffer overflow, malformed packets and DOS attacks is a significant concern - Amazon's freeRTOS being a prime (sorry!) example. This is becoming an important issue as goverments load on the pressure onto organisations, including power and water utilities, where significant disruption to society could result from their infrastructure being hacked. So what do you do if you want a secure, and preferably cheap, TCP/IP stack for an embedded product? It seems to me you have a few choices including:

a) Use a free product such as LwIP. This should be relatively quick to implement and have a small footprint having been designed for embedded products. But are they robust and maintained and tested against new attacks?

b) Port the latest Linux or BSD stack. I expect this to be a major undertaking, especially if you don’t need to, or have the resources to, support IPv6 so extracting the IPv4 code might be a nightmare. This has the advantage that Linux and BSD TCP/IP stacks are so widely used that they get a lot of attention from both attackers and defenders and any vulnerabilities get quickly patched.

c) Buy a third party stack. But how can you be confident that they are any more secure, and remain so, than free versions? The vendors will no doubt have a long list of reasons why (only) they can be trusted because obviously they have a team of the world's foremost TCP/IP and cyber security experts who are continuously engaged in probing and testing their S/W with the most advanced techniques to reveal any possible weakness, whilst diligently monitoring CERT alerts (and extensive inside contacts in various national intelligence agencies including GCHQ, NSA etc.)

But in the real world? How do you know that the product isn’t something that was written by ‘old Fred the comms whizz’ 25 years ago and has now retired and nobody at the vendor dares to touch beyond updating the copyright dates in the header files occasionally? If they do have a large dedicated team, chances are they are engaged in porting to innumerable different MCU/platform targets with their idiosyncratic tools and peripherals with little if no time to consider security. Especially as 'security' is very nebulous and virtually impossible to prove (prior to being hacked), whereas being able to tick the box 'Paduak MCS150C as a supported target' is likely much higher up a product manager's list of priorities.

Whatever the source of the stack, there is the vexed problem of keeping the firmware in an embedded product up to date. Clearly, having a TCP/IP stack means a large part of the update problem (distribution) should be solved (or at least simplified) but the remaining issues of managing the updates remain, including keeping track of the revision state of all products in the field and interoperability with earlier versions. Using a simple stack like LwIP presumably avoids this issue because it isn’t updated (but of course your porting might have errors which need to be fixed).

If you use a widely used stack then you probably need to be able to update quickly when vulnerabilities are found, which means a lot of cost in tracking updates by the developers, and porting those into your own if necessary, and distributing and managing your new releases. On the other hand if you use a (relatively) unknown or obscure stack then it’s possible that attackers will miss your unique vulnerabilities. I expect that this ‘security by obscurity’ does protect many embedded products - from casual attacks at least. But if your customer happens to be a high value target, such as a utility company sufficiently attractive for an attacker to focus their efforts on your stack, the ‘obscurity’ protection may become minimal or non-existent.

There are many more issues of course. So what do you do? Is the security weakness of TCP/IP stacks exaggerated? Falling victim to a DOS attack is likely nowhere near as severe as a breach allowing control/access to the device. Many of the high profile vulnerabilities of many consumer devices such as routers seem to be due to backdoors for developer or maintenance access, rather than in stack code itself.

What if your customer wants evidence that your product is secure - beyond bedazzling them with your gold-plated ISOxxxx/CMM level X quality systems and processes? How much does it cost to get an embedded product tested by a third party to 'prove' that it is secure?

And how could you rely on a third party's evaluation? Given the nature of attacks, testing requires creative and innovative approaches to testing as well as rigorous and methodical testing. The latter no doubt could be certified to ISOxxxx  (whatever standards developed by whatever committees) but that may add relatively little value to the former which requires individuals motivated to understand the mindset and techniques of attackers and constantly anticipate and investigate previously unknown or unused types of attack. These skills would be almost impossible to quantify in any sort of certificated form but are likely to be much more important than any size army of people with clipboards counting bytes, measuring stack depths, complexity metrics etc. etc.
Pages: [1] 2 3 4 5 6 ... 10 Next