Sorry, I thought there was some Wi-Fi going on here
Yes, have you tried this?
Hm. I donât think this will have an effect when the UNO is stuck, because the communication between PC and UNO is interrupted and the python can not send anything to the UNO or? I hoped there might be a way to reset the device via pin8 to ground...
No worries, i just use a UNO r3 without a Wifi option.
Well switching off the PC and then all the other gear, then switching all on again is like a full power circle and yes that makes everything operational. The aim was to keep the PCs running 24/7 because it is easier for the people who are operating the venue and additionally the PCs have remote access. If the PCs can not stay on 24/7 it is no big deal i guess. And considering the latch up which might happen here i actually prefer a proper shutdown of the PC before the rest gets switched off. So if the hardware switch and the UNO are still working tonight, i call it a day and consider the issue resolved. Thanks.
Well done, I am glad that recovers the situation. 
Given the live operation of the show then I guess that is the best short term option. However, for the future you can stop this from happening by changing the circuit and adding diodes to stop this parasitic powering from occurring, and hence stop the latchup. This is something you have to do when designing things with a power down mode. I had to do this when I was designing digital set top boxes.
However, as we have not considered the hardware and not even seen a schematic I think that is for another thread.
I already read about it. Could you point me to some instructions how to beat the parasitic powering? If it is something i have to add to the UNO i reckon i can do it. But maybe the powerdown does affect the PC too? This is out of my scope but i have a few more days left to improve the setup. Someone recommended also using ESP32 instead of the UNO.
Well i guess i just search in this forum on how to tackle that issue.
The big problem with this processor is that it is only a 3V3 processor and you probably would have to do a lot of voltage shifting for it to work. I would stick with the Uno.
It depends entirely on you circuit, do you want to post a full schematic and then we can discuss it?
i will do that. shall i better make a new thread? i think yes.
Yes I think so. Mark this one as solved, and post a link to the new thread here.
Post the new thread in the Project guidance section.
OK. I will close this tonight or tomorrow once i have finshed the final long term test with the switch. As i said the failure sometimes occured after days, so i better be thorough : )
1 Like
Schematic is here in a new thread:
https://forum.arduino.cc/t/parasitic-power-problem-arduino-uno/1264346
In the course of the discussion i assumed that it is clear that if the PC is on the Arduino is always on too because it is mentioned in the very first comment i posted that is powered by the USB port. However later on I said âif the PC is on and all other gear is switched offâŚâ and that is wrong because that what include the Arduino being off. That is not possible in my setup. PC on means Arduino is on. PC is off means Arduino is off.
I have done two longer test cycles now. Both player fail. After 10 hours swtich behaviour becomes laggy, then the switch does not respond anymore. I first thought they behave differently but the timing of failure is just a bit different.
Clean slate. To avoid other potential (hardware interference) i took one the systems out of the exhibition space and set it up in the office. No long wires attached, minimal setup. I want to reproduce the failure of the arduino by actually doing nothing: not triggering the sensor, not touching the swtich.
Why? Because isn´t that what happens here? The system runs in a space with no interaction of anyone for serveral hours, then the language switch becomes laggy and fails. When there is no interaction, the python script plays just a short video in a loop. Keep in mind the sensor always works, and so does the PC. It is the Arduino who has "enough" after x hours.
Regarding the photo: The small case is the grounded Arduino casing and what seems to be the DC input is NOT the DC input. That is the connector for the switch. If you suspect any issue here already, please let me know.
You have two topics regarding this setup. I know that you were advised to start a new one about hardware issue which was sensible. But now the question is where you want to continue, in this topic or in the other one.
I'm tempted to merge both topics or move your post #35 to the other topic. The reason is that you run the risk that you will get replies in both topics where people don't know that others already gave a reply which will waste people's time. Please let us know what you prefer.
Very kind. I was already wondering. I´d say let me run the stripped down versions without the long cables for a while longer. If no error occurs on both players then it is very likely that the cable is the culprit. If the office version without long cable runs ok but the exhibition version without the long cable attached fails something else is going in that space. Does that makes sense?
Please let us know.
Let´s stay here please for now because:
I am able to make the Arduino NOT responding to the language switch anymore after 10-15 min by randomly toggling the switch. I reapeated that process multiple times, time varies when the failure occurs. So the playlist is then stuck in one language but the sensor still works as intended.
When i then leave the video fullscreen mode and look at the console i still get
'Raw data received: b'\x01)\x01\xee\n'
each time i toggle the switch, however the playlist language does not change.
I activated more print commands in python and recreated the failure and got:
Debug message: bytearray(b'\x01\xee)
I am using extra short cables for the switch. very basic setup as shown on the previous photo.
So i am i right if i say that the Arduino actually does not hang but the python is not processing any more? I can recreate the error with all 3 Arduinos UNO r3 i have.
No that is not a conclusion you can make.
OK so you have tested it and you get a failure. This happens quicker if you toggle the switch, so that means the switch circuit needs attention. So take the advice given to you and place a 0.1uF ceramic capacitor between pin 8 and ground. Make the leads of this capacitor as short as you can, and then see if you can induce the fault by repeatedly flicking the switch.
Yes that was my current plan, i orderd the parts. I guess the switch just creates noise sometimes and that results in corrupted data. I still dont know if shall use just one capacitor, or two or as well a resistor. I have a lot of advice here, which is great but i am not sure if i shall intergrate all of it? Or just start with the one capacitor between pin 8 and GRD and then progress if that does not resolve the issue?
The problem is that it is now spread over two threads. And that is why I think they should be merged.
Not sure where the resistor is but two capacitors is a good starting point, because at the moment something is on the edge of working, so even if you could get it working with just one capacitor, it will be more reliable with two.
If it is noise this is dependent on the RF environment you find your self in, and you have no control over that, so the more robust you can make it the better.