<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[Topics tagged with shared pins]]></title><description><![CDATA[A list of topics that have been tagged with shared pins]]></description><link>https://forum.pycom.io/tags/shared pins</link><generator>RSS for Node</generator><lastBuildDate>Thu, 18 Jun 2026 11:30:56 GMT</lastBuildDate><atom:link href="https://forum.pycom.io/tags/shared pins.rss" rel="self" type="application/rss+xml"/><pubDate>Sat, 20 May 2017 12:08:39 GMT</pubDate><ttl>60</ttl><item><title><![CDATA[Using Sigfox and UART 1 causes instability]]></title><description><![CDATA[@jmarcelino
Yes, my problem is the same as what you highlight, thanks for solving the mystery.
As an temp solution (for lazy ppl) I can suggest :
# hard reset if last was a soft reset
if reset_cause() == 4:
    reset()
if not 'sigfox' in locals():
    sigfox = Sigfox(mode=Sigfox.SIGFOX, rcz=Sigfox.RCZ4)

Regarding the UART1 activity causing Sigfox instability, I will do more tests later.
Maybe update the SiPy pinout PDF to include the UART1 pins (like LoPy) as @livius mentioned?
]]></description><link>https://forum.pycom.io/topic/1248/using-sigfox-and-uart-1-causes-instability</link><guid isPermaLink="true">https://forum.pycom.io/topic/1248/using-sigfox-and-uart-1-causes-instability</guid><dc:creator><![CDATA[noxqs]]></dc:creator><pubDate>Sat, 20 May 2017 12:08:39 GMT</pubDate></item></channel></rss>