there is very little chance of a user actually getting into trouble because of it.
Meh, I wouldn't qualify the flash problem as 'really bad' before, or really at all noteworthy now.
Meh, I wouldn't qualify the flash problem as 'really bad' before, or really at all noteworthy now.
It's just as noteworthy now as it was back then.
Since the Rasberry PI 3, is an extremely good value for money, educational/simple computer system, they are aiming for the $29.99 market. Many computers are $299.99 or even $999.
They may have decided that the issue is not important enough to fix and/or it will be fixed when the new generation eventually comes out and/or they will eventually fix it in the current model.
I bet if you properly/thoroughly investigated the system, you could find at least 10 detectable problems/bugs/issues.
So you have to continuously use the WiFi
obtain a rare expensive professional (I'd imagine) powerful flashed camera
Then you act like this problem is a complete disaster, on a fun $29.99 computer ?
The top chip being susceptible is still at least a minor issue I guess. But you have to go so close with the flash now, it does not seem too bad.
I'm not convinced this is a serious problem now.
ping 8.8.8.8Long post, see above for original
Next time if you want to check the status of a network link continuously you could useCode: [Select]And it will ping continuously on *unix. On Windows you need to add -t.ping 8.8.8.8
To stop press ctrl+c.
Analogy:
How would you react, if someone made a Youtube video, which seemed to "attacked" Fluke multimeters ?
I don't know if what I am saying makes any kind of sense ?
I think the real engineering issue is whether the RPi resets because of the light getting into photosensitive areas of some chips or the magnetic pulse from a Xenon flash. Try covering the board with something opaque, that will eliminate the light issue. My guess is that it's a magnetic pulse issue.
With the RPi2 it was most definitely lightUndoubtedly it was light on the RPi2 but if you cover the light sensetive area and then try a Xenon flash at the same distance, if it still resets then it's a magnetic coupling problem. di/dt is quite high in a Xenon flash and and it probably deosn't take much flux linkage to induce enough volts into a high impedance track. How is the ground plane arranged, if there is a slot in the ground plane then there will be an induced voltage across the slot for example.
I think the real engineering issue is whether the RPi resets because of the light getting into photosensitive areas of some chips or the magnetic pulse from a Xenon flash. Try covering the board with something opaque, that will eliminate the light issue. My guess is that it's a magnetic pulse issue.With the RPi2 it was most definitely light. It's very likely the same issue now, as although they've changed the package, the silicon should still be exposed underneath.
You've put "AGAIN!" in capitals. My first impression was that you are criticising them for not ensuring the issue was resolved once and for all.
If anything this seems like a video that didn't need to be made.
If anything this seems like a video that didn't need to be made.
I think you have a distinct lack of imagination.
The original RPi2 problem was very well publiciced, and it would be very easy for someone to see that and ask the question "Does that happen on the RPi3 as well or have they fixed it?"
I know, because I asked that exact same question myself, so I did a quick search and couldn't find the answer, so I did a video on it.
Next time if you want to check the status of a network link continuously you could useCode: [Select]And it will ping continuously on *unix. On Windows you need to add -t.ping 8.8.8.8
To stop press ctrl+c.
Didn't know that, thanks.
sudo ping -s 8 -A <router ip-address>Next time if you want to check the status of a network link continuously you could useCode: [Select]And it will ping continuously on *unix. On Windows you need to add -t.ping 8.8.8.8
To stop press ctrl+c.
Analogy:
How would you react, if someone made a Youtube video, which seemed to "attacked" Fluke multimeters ?
I've done one:
https://www.youtube.com/watch?v=-13Q-UsXKQM (https://www.youtube.com/watch?v=-13Q-UsXKQM)
And many others for brands and products I'm big fanboy of.
I'm a bit confused. Doesn't the PE effect only work for UV light that has enough energy to knock off some charge carriers? Why do they say a laser pointer has the same effect? Shouldn't most laser pointers be low frequency red light? I know the semiconductor industry uses UV light for photoresist for etching into the silicon, but that's still UV. Any clues here?The UV light cannot penetrate very deeply into silicon, so while it has more energy the red light is getting further into the silicon which could be causing problems.
Just shot a follow-up video to this and lost ALL the footage because of that stupid SD card bug in the Canon HF G30 :rant:
At the risk of repeating myself, the big guns at Canon should be taken out the back and shot. :rant:
At the risk of repeating myself, the big guns at Canon should be taken out the back and shot. :rant:
The exact same bug is possible on my Sony NEX-VG30, it ain't just Canon.
I should probably test the WiFi chip better though, but i couldn't get it to fail when the board was flipped over, no matter how close.
What happens if it is exposed to a professional photo flash set up, there is many times more energy from those. Will it kill the chip permanently and from what distance etc.
https://www.youtube.com/watch?v=_D_fi_ck9Vo (https://www.youtube.com/watch?v=_D_fi_ck9Vo)
Mk14, Simple, the phototransistor has the junctions exposed deliberately, with only a clear oxide layer over them. The IC has the junctions buried deep in the silicon, and you are putting the light through a thick layer of absorbent silicon, which is somewhat transparent to light in the IR while it is opaque to most visible light.Thanks, I'm very impressed with you answer, which has taught me a lot.
The EPROM also deliberately exposes the floating gates, which is the charge store for the memory, so you can erase it by providing enough UV light to cause the electrons to tunnel through the thin oxide layer erasing the cell. Slightly different in that they use a floating polysilicon gate electrode in an insulating oxide layer as a gate to control a MOSFET switch, with another gate very close to it that is used only during programming to place a charge in the gate by quantum tunnelling.
What I find weird is ithat I have a version of raspberry pi 2, that doesn't seem to have a U16 on it.
The layout of the power supply area is also completely different.
I can't test for the issue since I don't have an slr with a xeon flash.
You will note that the board from the original video dave did it said Raspberry pi B+ 1.1
However mine is a 1.2 BUT the new video is clearly for version 3.
(https://www.eevblog.com/forum/blog/eevblog-901-raspberry-pi-3-photoflash-problem-again/?action=dlattach;attach=241044;image)
Mk14, Simple, the phototransistor has the junctions exposed deliberately, with only a clear oxide layer over them. The IC has the junctions buried deep in the silicon, and you are putting the light through a thick layer of absorbent silicon, which is somewhat transparent to light in the IR while it is opaque to most visible light.Thanks, I'm very impressed with you answer, which has taught me a lot.
The EPROM also deliberately exposes the floating gates, which is the charge store for the memory, so you can erase it by providing enough UV light to cause the electrons to tunnel through the thin oxide layer erasing the cell. Slightly different in that they use a floating polysilicon gate electrode in an insulating oxide layer as a gate to control a MOSFET switch, with another gate very close to it that is used only during programming to place a charge in the gate by quantum tunnelling.
I see, so because only certain parts of the EPROM are actually exposed, which can be carefully/precisely controlled by the masks (or similar) and IC production processes etc. Although to the human eye it appears the chip is "fully" exposed. In reality it is not. Only the parts which need to be erased.
For serious/reliable EPROM usage, it was needed to cover the UV window, ideally with proper UV/EPROM stickers (pricey, because they had an aluminium/metal film), or the cheaper solution was to just use paper labels. Otherwise they would sometimes mis-operate under bright light or even normal light, or maybe even eventually self erase.
Now I understand a lot better, why it is so difficult to get this problem to occur. Thanks again!
I fell foul of this once, I think it was a 27C011 that wouldn't program in a bright sun lit room, but would in an artificially lit room.
It turned out out that the same die was used for both the 27C010 (might have been the 27C101 it was a long time ago) and the 27C011.
One was 16bits wide and the other was 8 bits wide and a non erasable fuse was programmed at the factory to determin which part it was eventually going to be. In sunlight the state of this fuse would flip and it became the other part until the light was removed. Our customer blamed us for having a faultly programming algorithm but sticking a label on it solved the problem. We informed the manufacturer who fixed the issue in a later die revision.
I think people program their chips, typically before covering the UV window, anyway. So it was a bad problem.
You're pretty much spot on with that explanation. I used to work for a programmer manufacturer and there were literally hundreds of variations of that algorithm across the many manufacturers.
I'm sure the cause is UV light, but keep in mind that the black tape is probably filled with carbon black. Can black tape block the electrical pulse from the flash electronics, even though the conductivity of the tape is not high?
I must be old. I remember having to black texta all over OC81 transistors (if memory serves) to ensure that they weren't acting as inadvertent photo transistors.I remember scraping the paint off an OC71 to make an OCP71.
This *may* have been a few years ago.
So what if it has a minor known issue. Known issues are easier to workaround. I'll take $29.99 with a known issue over a $500-$1500 system with a close source OS that has random unpublished issues.
Why are people attempting to come up with alternative theories? Flip chip devices are well known to be more sensitive to light, and Dave has done plenty enough to confirm this is the cause in this case.
My work provided laptop did a BSOD last weekend, its a 6 month old laptop and cost $1200. Back when I worked for a reseller we had one customer with an $Apple$ costing $2000 and he must have sent that thing back to Apple 6 times in the first year. I upgraded my web server from an RP2 to an RP3 when the 3's were first available, the 2 ran for over a year, maybe once or twice I rebooted when a kernel update was released but no problems.
So what if it has a minor known issue. Known issues are easier to workaround. I'll take $29.99 with a known issue over a $500-$1500 system with a close source OS that has random unpublished issues.
So what if it has a minor known issue. Known issues are easier to workaround. I'll take $29.99 with a known issue over a $500-$1500 system with a close source OS that has random unpublished issues.