Guru Meditation Error & Magnetic Interference (EMI/RFI)
-
@combaindeft said in [Guru Meditation Error & Magnetic Interference (EMI/RFI)]
Nothing that fancy, just a place in the middle of Nowhere.
It just happens that there is a High Voltage Power Line crossing it - Map to Field @ Nowhere
Yeah thats pretty isolated. Couldnt see anything myself other than the powerlines that could cause it at least with the minimal view streetview gives. presuming there's nothing buried below that field at least :P
-
@combaindeft If you happen to see this before your field test. It may be handy if you could install one of the EMF detector style app's for mobiles you can get. they wont be super accurate but it should give us an idea if "something" is going on.
Just grab a couple of reading's at various ranges from the powerline.
-
@martinnn said in [Guru Meditation Error & Magnetic Interference (EMI/RFI)]
@combaindeft It would be really interesting to know what type of environment you have. At 100 kW radio transmitter? Inside a nuclear reactor?
Nothing that fancy, just a place in the middle of Nowhere.
It just happens that there is a High Voltage Power Line crossing it - Map to Field @ Nowhere
Generally I'd say the Wipy (or any other module) is not "CE compliant" in a product sense - obviously any ESD event will kill the device instantly. That's OK because it is a component. If you build a product with it, it is your responsability to make sure the relevant EMC regulation requirements are fullfilled (usually by getting a certificate from a test lab). Pycom provides RED certificates here: https://docs.pycom.io/documents/certificates.html - but this is RED only (the radio part). Anything else (ESD, conducted, magnetic...) is up to you. So if you choose to operate this component inside an MRI machine, it is your responsability to provide adequate shielding. Of course Pycom can make your job easier or more difficult by providing a design that is super sensitive and resets with the lightest disturbance or one that is extremely robust
Yeah, we're not complaining about who's responsible and such ... just as I highlighted in bold ... it would just make it easier if the devices where "more robust" ...
But in the end you put the CE mark on your product!
mmm, and for that step we're going to design something from the ground up ourselves with ...
but for "as close to street product level we can get with development boards" ... it would make it easier for us in our R&D in finding the right solution for the customer ...
Instead of spending more time on playing MacGyver :-)
So if you want your design to work at a specifically nasty environment, it seems you have to learn something about EMC/EMI...
Japp, looks like we're play MacGyver ... it's fun from time to time :-)
-
@crumble that's the challenge. EMC gurus have to make a living too, not just meditating gurus!
-
@martinnn said in Guru Meditation Error & Magnetic Interference (EMI/RFI):
But if you shield the pytrack you have only an expansion board 3 with a reduced amount of pins ;)
-
@combaindeft It would be really interesting to know what type of environment you have. At 100 kW radio transmitter? Inside a nuclear reactor?
Generally I'd say the Wipy (or any other module) is not "CE compliant" in a product sense - obviously any ESD event will kill the device instantly. That's OK because it is a component. If you build a product with it, it is your responsability to make sure the relevant EMC regulation requirements are fullfilled (usually by getting a certificate from a test lab). Pycom provides RED certificates here: https://docs.pycom.io/documents/certificates.html - but this is RED only (the radio part). Anything else (ESD, conducted, magnetic...) is up to you. So if you choose to operate this component inside an MRI machine, it is your responsability to provide adequate shielding. Of course Pycom can make your job easier or more difficult by providing a design that is super sensitive and resets with the lightest disturbance or one that is extremely robust. But in the end you put the CE mark on your product!
However, even fullfilling the relevant CE immunity requirements will not make sure your product works everywhere. EMC limits are set so that most devices interoperate reasonbly. That means if you switch on a kitchen blender, the TV won't go black. You take that TV inside a HVDC plant and probably it won't survive that - which is OK, because nobody lives there and that requirement would make a TV ridiculously expensive.
So if you want your design to work at a specifically nasty environment, it seems you have to learn something about EMC/EMI...
BTW a friend once told me they built cameras for the Tchernobyl cleanup. They used a picture tube with discrete radiation hard components only, encased in a massive lead block. These lasted a few hours on site before they were destroyed by the radiation. So it all depends...
-
@combaindeft Thanks. much appreciated :)
-
@paul-thornton okidokeli-do :-)
After tomorrows field test I'll do that.
-
Hi @combaindeft
It would be usefull if at all possible to get the output of some of the core dumps when its in its issue state. You can post there here or email them to paul@pycom.io,
Thanks :)
-
@combaindeft Thanks for the report and the investigation work. Ill raise this with the team as something to look into. clearly this shouldnt be an issue.
-
Scenarios we ran:
A) With USB-cable
-
As soon as it started to happen, we unplugged it ... but the device wouldn't come back to life ... it just ran around in an endless "Guru Meditation Error" & "Core Dump" loop ...
-
Tested different cables to ... since there are "good shielded usb cables" and then there are "GOOOD shielded usb cables" ... neither helped.
-
Only driving a bit farther away helped ...
B) No-USB--Cable
-
Since we programmed in different RGB Led Colours into the code sequence ... we could simply by looking at it know what it was doing / supposed to do...
-
Not even the "Heartbeat" (blue flashing color) come to life ... and since we knew what colors to expect when it ran the code ... it was quite easy to come to the conclusion that it was running around in an endless "Guru Meditation Error" & "Core Dump" loop too ...
-
We could confirm that it was, by swiftly hooking it up with a USB-Cable, that it was indeed in the Guru-Core-Dump-Loop
-
and yes, we did unplug the battery too, reset it in every conceived possible way ... though only driving a bit farther away helped ...
NOTE: In booth Scenarios, we ran with our own code ... and freshly reset-and-firmwared (no code running, as we wanted to exclude that it wasn't our code that was bonkers) ...and as soon as we left the area ... they just booted back up and ran the code ... or was just idling with the "Heartrate" led flashing ...
PS: We will do some more field testing tomorrow .... and we shall document with logs and images / video this issue.
-
-
Interesting... would be nice to see your setup! I doubt magnetic interference could be an issue (but who knows, you write BIG power lines...). In EMC compliance testing, there isn't even a test for magnetic immunity. Of course there is electromagnetic immunity, but the biggest influence will come from the connecting cables (unless you run on battery), acting as antennas and picking up all kind of noise.
Now that you say it I also think that I get guru errors only from USB connected devices. I have a couple of wipys running standalone with wall plug supply which as far as I remember seem to do fine. Of course you would not see the guru message in an unconnected standalone setup.