I have had 2 photon today that start to breath red - no idea what this means. Can anyone help?
I guess itās not pure red but rather magenta (red + blue), which indicates Safe Mode.
But to be sure, can you post a video of the startup process plus 10sec of the final state?
2 Likes
I canāt post a video at the moment but believe me it is red and not magenta. I can unpower the photon and repeat the sequence - it appears to happen some time (circa 20s) after startup (normal). It gets triggered after a signal that takes pin D2 from 5V down to Ground. Must be something to do with that signal. Oh - have also seen red flashes SOS then one red flash then breathing red.
The easiest way to post a video here is to upload on YouTube and post a link.
Breathing red is completely unknown to me (unless some of the RGB LED GPIOs are faulty).
1 Like
Thanks for the quick responses - @ScruffR you may be on to something because I have seen other photons where another pin (D3) was made. Sorry - I can post a video but just not now as I am in a customer workshop.
Feedback on this after some investigation of the root cause and using a DSO highlighted that cable management was the issue/cause of the failure.
I have a PS2 keyboard input which uses pins D3 for data and D4 for the clock. What appears to have happened which came out of the blue (there have been 20 systems working fine to date) is that the keyboard trailing lead to the DIN 6 pin socket was lengthened (unknown to me) to fit a taller product installation and was then also tied along a length of 80cm to a mains lead from an external socket to a battery charger. The mains lead only had current in it when the device was plugged in for charging. Out of 16 devices - 11 showed no keyboard response after having been charged and it transpired once I tested them that all of the photons in these devices had either pin D3 or D4 no longer working. Some had D4 on HIGH output. Using a PCB without the photon in place it appears that even when there is no keyboard plugged, when the mains charging was started there was a spike of voltage on D3 and D4 which appeared ever so briefly to exceed 5V. I assume that even though this was likely a low current it would have been sufficient to fry the pin and knock the application out, hence the red LED.
I have been able to reload the firmware and test the PINs and whilst the D3 or D4 pins are damaged the other PINs all appear to work OK. I am looking at better cable management to keep the keyboard lead away from the mains leads and to eliminate the need for the keyboard.
General concern now is that any length of DC cable (to a switch) if near to a mains cable could end up being fried in the someway. Any insight from @peekay123 about the best ways to avoid this apart from keeping wires apart - optocouplers?
Mains = 240VAC here in the UK. Picture here should clarify the setup. White tape was used to try various cable layouts. In this picture the white cable is a 3 core single phase AC (L, N, earth). The multi-colour 4 way ribbon is the keyboard cable. The actual installation had the white mains cable looped back on itself (3 cables in parallel). The setup here showed over 1Vpp with a steady charge and more on initial current inrush to the charger which is just out of picture above the 3 sealed lead acid batteries.
@armor, that long a keyboard cable is bad to start with. Ribbon cables need to have alternating GND and signal cables and even then, capacitance and noise problems will persist. I suggest a multi-conductor shielded cable for the keyboard with proper connectors on both ends. Even without nearby power conductors, long parallel cables are not good since they are really good antennas!
2 Likes
@peekay123 Thanks for the advice about the shielded cable.
I am working towards removing the keyboard by using SoftAP for wifi setup and control settings via Particle Functions.
What do you mean by āproper connectors on both endsā? Are you referring to the shielding being connected to the chassis.
I am looking at another product with a load of sensors sending TTL signals back to a GPIO and all this sat in a cabinet with loads of power (AC) cables and charging adaptors. Is shielded cable sufficient with this or should I be looking at putting optocoupling before the GPIO expander?
@armor, long parallel cables for GPIO are never a good idea. Depending on the distance, you could consider having an I2C port expander gathering the TTL signals at the product and only have a 4-wire shielded cable going back to the Photon (I2C, Vcc and GND). You would need to filter the power carefully at the expander.
If the TTL signals are slow changing and rise time is not an issue, you could use opto-couplers or line drivers for the parallel cable, alternating signal and ground wires. As shield ribbon would be good.
1 Like
@peekay123, Thanks for your advice. I have done some research on shielding and have now implemented a foil wrapped (woven/braid is best but too expensive) 4 core with twisted pairs cable instead of the 4 way ribbon. I have grounded the foil wrap at the MCU end only. Have also ensured that this cable is kept at least 7cm from any AC cables. I have another shorter 10 way ribbon between PCBs. On this I have grounded 4 unused cables at the MCU end and again tried to keep at least 7cm between it and any AC cable.
1 Like