Sector5Dhttp://sector5d.org/2017-02-20T14:10:00+01:00Solving timekeeping issues on an offline Nest thermostat2017-02-20T14:10:00+01:00Derechotag:sector5d.org,2017-02-20:solving-timekeeping-issues-on-an-offline-nest-thermostat.html<h2>The issue</h2>
<p>Some time ago I received a smart Nest thermostat as part of a promotional offer.
I wasn't very keen on the idea of having something like a thermostat phoning
home to a centralised server in the "cloud", but it was a good deal and the Nest
does still offer some benefits over a traditional dumb thermostat even when it
has no access to the internet. I have a good number of reasons for wanting to
keep the thermostat disconnected from the internet and I will not go into them
here as that is not the point of this article.</p>
<p>There is one downside to keeping the Nest disconnected though; it's not very
good at keeping track of the date and time. In fact, it's quite bad at it
actually, I'd see it reset to January the 1st 1970 every few days or weeks. As
a result, this messes up your heating schedule and you might find yourself
being in a cold house when you'd expect it to be warm, or the thermostat might
instruct your heating to turn on in the middle of the night wasting unnecessary
energy and money.</p>
<h2>Looking into Nest traffic</h2>
<p>The behaviour as described above indicates that the Nest lacks a proper RTC,
or realtime clock. Searching on the internet on several occasions did not
yield me many useful results, it appears that most users of the thermostat do
not suffer from this problem. This led me to believe that the thermostat relies
on some sort of network service to periodically query the time and adjust
itself. I suspected it was using the well-established NTP protocol for this,
and set out investigate.</p>
<p>As I have OpenWRT running on my router, I added a firewall rule to block all
traffic going from the LAN to the WAN for the MAC address of the Nest. I used
LuCI for doing this but you can also use <code>uci</code> over ssh if you prefer. You can
find out the MAC address of your Nest before connecting it to a network by
going into Settings > Technical Info and scrolling all the way down until you
see it listed.</p>
<p>After this, I felt comfortable configuring the thermostat to connect to my WiFi
AP and to inspect the traffic it would generate. For this I am using <code>tcpdump</code>
on the router and examining the capture files with Wireshark on my desktop.</p>
<p>When I did this I noticed I made a small mistake, I blocked the wrong MAC
address from accessing the internet and my Nest did in fact phone home. While
being connected for less than 5 minutes, it submitted some sort of statistical
data to the Nest servers and pulled in a firmware update. I had no way of
preventing this update after it was pulled in, though I don't mind that as much
as the statistics it managed to send off. So, make sure you block the right MAC
address or just even pull the cable to your modem entirely if you want to be on
the safe side.</p>
<p>After quickly correcting my firewall rule, I noticed the Nest was not too happy
with the connection. It'd try to connect and upon finding that the internet
wasn't accessible it'd disassociate from the AP again. The new firmware it
pulled in is more tolerant of the restricted network capabilities, it stays
connected to the WiFi AP without much complaining. Looks like my little mistake
did end up benefitting me after all.</p>
<p>On to addressing the issue at hand, which is timekeeping. I noticed some very
convenient behaviour in the traffic I analysed. The Nest does indeed rely on
NTP for keeping time, and it actually tries to query your network's gateway
for it first! In my case that meant it was trying to connect to an NTP server
on my router which I did not have running. After a few failed attempts, it
resolves <code>time.nest.com</code> and queries that instead.</p>
<h2>The solution</h2>
<p>At this point there are three possible approaches I can think of to give the
Nest the time information it seeks:</p>
<ol>
<li>Host an NTP daemon on the router</li>
<li>Redirect DNS queries for <code>time.nest.com</code> to a machine within my LAN that has an NTP daemon running</li>
<li>Explicitely allow NTP requests to access the internet</li>
</ol>
<p>I decided to go for option 1 as it seemed the simplest and most direct way of
remedying the timekeeping issues whilst keeping all control.</p>
<p>For OpenWRT there are various ways to host an NTP daemon, but the quickest way
to accomplish this without pulling in any extra packages is to use the ntpd
that is compiled into <code>busybox</code>. Instructions on how to do this may be a little
unclear online as it seems to be a recent inclusion into OpenWRT, but it is in
fact very simple.</p>
<p>Connect to your OpenWRT/LEDE router over ssh and open up <code>/etc/config/system</code>
in your favourite editor. There will be a section describing the NTP
configuration:</p>
<div class="highlight"><pre><span class="n">config</span> <span class="n">timeserver</span> <span class="err">'</span><span class="n">ntp</span><span class="err">'</span>
<span class="n">list</span> <span class="n">server</span> <span class="err">'</span><span class="mf">0.</span><span class="n">openwrt</span><span class="p">.</span><span class="n">pool</span><span class="p">.</span><span class="n">ntp</span><span class="p">.</span><span class="n">org</span><span class="err">'</span>
<span class="n">list</span> <span class="n">server</span> <span class="err">'</span><span class="mf">1.</span><span class="n">openwrt</span><span class="p">.</span><span class="n">pool</span><span class="p">.</span><span class="n">ntp</span><span class="p">.</span><span class="n">org</span><span class="err">'</span>
<span class="n">list</span> <span class="n">server</span> <span class="err">'</span><span class="mf">2.</span><span class="n">openwrt</span><span class="p">.</span><span class="n">pool</span><span class="p">.</span><span class="n">ntp</span><span class="p">.</span><span class="n">org</span><span class="err">'</span>
<span class="n">list</span> <span class="n">server</span> <span class="err">'</span><span class="mf">3.</span><span class="n">openwrt</span><span class="p">.</span><span class="n">pool</span><span class="p">.</span><span class="n">ntp</span><span class="p">.</span><span class="n">org</span><span class="err">'</span>
<span class="n">option</span> <span class="n">enabled</span> <span class="sc">'1'</span>
</pre></div>
<p>After these existing options defining the nameservers and enabling the client,
add the following line:</p>
<div class="highlight"><pre> <span class="n">option</span> <span class="n">enable_server</span> <span class="sc">'1'</span>
</pre></div>
<p>Save the file, exit, and run <code>/etc/init.d/sysntpd reload</code>. You're done! At this
point you can verify that the ntp daemon is up and running by issuing
<code>netstat -l</code>; it should now show that there's a service listening to the NTP
port. Further traffic analysis of the Nest shows me that the Nest is indeed
getting an NTP response from my router and that it doesn't bother to query
<code>time.nest.com</code> after that.</p>OpenWRT on the Ubiquiti EdgeRouter X2016-04-17T14:00:00+02:00Derechotag:sector5d.org,2016-04-17:openwrt-on-the-ubiquiti-edgerouter-x.html<p><img alt="The Ubiquiti EdgeRouter X running OpenWRT happily" src="/images/erx_closed.jpg" /></p>
<h2>Choosing the Ubiquiti EdgeRouter X</h2>
<p>As I will be moving soon I will be needing a new router for managing my home
network. There are hundreds of routers availble at various prices in many stores
but I knew I wanted something beefier than most consumer routers and preferably
run my favourite router firmware on it: OpenWRT. With that in mind, I
researched a handful of candidates and decided on the Ubiquiti EdgeRouter X.
It's a small 5-port gigabit router with no wireless support but sports a
dualcore Mediatek MIPS processor and has both 256MB of RAM and NAND Flash.
The inreased RAM and Flash size compared to most consumer routers would come in
very handy with OpenWRT as it would allow me to install plenty of extra
software packages later on, and allow me to use the storage for saving any logs
or other files. The lack of WiFi support didn't bother me, this router will be
mounted near my front door where the cable modem will reside and I would like
my WiFi AP to have a somewhat more central location in the house anyway.</p>
<p>So, I had chosen for this EdgeRouter X, but I knew there was one catch: barely
any information on getting OpenWRT on it seemed to be available.
The
<a href="https://wiki.openwrt.org/toh/hwdata/ubiquiti/ubiquiti_edgerouter_x">OpenWRT techdata page</a>
listed some of the router's details but little else, and the
<a href="https://wiki.openwrt.org/toh/ubiquiti/ubiquiti_edgerouter_x_er-x_ka">OpenWRT device page</a>
was almost completely barren. It did however feature a picture of the internal
serial port, which came in handy later. The most promising resource appeared to
be
<a href="https://forum.openwrt.org/viewtopic.php?pid=299587">a topic on the OpenWRT forums</a>
which showed that at least two people had gotten OpenWRT running on it, and
that gave me just enough hope to give it a try myself.</p>
<h2>A first look at EdgeOS</h2>
<p>The Ubiquiti EdgeRouter X comes with the EdgeOS firmware by default. Contrary
to the stock firmware on many consumer routers, this firmware is actually
regarded as pretty decent and provides many features. Before flashing OpenWRT
on the router, I had a little look around EdgeOS first.</p>
<p>After logging in on the web UI, the user is presented with some general live
graphs on the first page and a status for all five ethernet ports. From here on
many settings can be configured on either the main page or any of the other
pages. I did notice however that my browser asked me if this website was
allowed to run Flash. Why a router needs Flash on its web interface is beyond
me.</p>
<p>SSH is enabled by default and you can log in with the same user credentials
as for the web interface. Upon logging in, surprisingly enough I am greeted
with a real bash shell. The linux version appears to be 3.10.14, and the
presence of a <code>/etc/debian_version</code> file (containing "7.8") hints to me that
the firmware is based on Debian. I wouldn't be surprised if it would be
possible to use the official Debian repositories to install additional packages
on this firmware.</p>
<p>As a last step before waving EdgeOS goodbye, I inspected <code>/proc/mtd</code> and used
dd to make images of all the partitions, just in case. Here's the layout:</p>
<div class="highlight"><pre><span class="gp">ubnt@ubnt:~$</span> cat /proc/mtd
<span class="go">dev: size erasesize name</span>
<span class="go">mtd0: 00080000 00010000 "SPI_FLASH"</span>
<span class="go">mtd1: 0ff80000 00020000 "ALL"</span>
<span class="go">mtd2: 00080000 00020000 "Bootloader"</span>
<span class="go">mtd3: 00060000 00020000 "Config"</span>
<span class="go">mtd4: 00060000 00020000 "eeprom"</span>
<span class="go">mtd5: 00300000 00020000 "Kernel"</span>
<span class="go">mtd6: 00300000 00020000 "Kernel2"</span>
<span class="go">mtd7: 0f7c0000 00020000 "RootFS"</span>
</pre></div>
<p>I'm not entirely sure what the <code>SPI_FLASH</code> is used for, but the firmware
resides on the NAND flash (recognisable by the different erasesize). The <code>ALL</code>
partition covers the same memory as all the following partitions toghether.
U-Boot and its configuration resides on mtd2 and mtd3 respectively. The
<code>eeprom</code> partition probably contains some settings for the router hardware,
though I can't be too sure. After that two kernels are present, the second one
as a fallback in case of a bad upgrade or flash corruption. Finally, the last
and largest partition is used for the RW root filesystem (ubifs).</p>
<h2>Compiling the OpenWRT images</h2>
<p>The forum topic that I mentioned in the introduction of this article included a
post that referred to a
<a href="https://lists.openwrt.org/pipermail/openwrt-devel/2015-November/037540.html">patch submitted in November 2015</a>
introducing support for this specific device. This patch would've been too
recent to have made it into a stable release of OpenWRT yet, so this meant I
was going to be running the trunk version. The techdata page links to a nightly
built trunk image specifically for this device, but this image is a sysupgrade
image. When you are still running the stock firmware, this image won't do.
The router needs to already be running OpenWRT if you want to use the
sysupgrade image. For the purpose of getting the router on OpenWRT in the first
place, so-called factory images are used. Looking through the nightly built
trunk images, there was a noticable lack of this factory image however. Time to
compile my own.</p>
<p>I set up a new OpenWRT buildroot environment as per the instructions:</p>
<div class="highlight"><pre><span class="go">git clone https://git.openwrt.org/openwrt.git</span>
<span class="go">cd openwrt</span>
<span class="go">./scripts/feeds update -a</span>
<span class="go">./scripts/feeds install -a</span>
<span class="go">make menuconfig</span>
</pre></div>
<p>At this point, you will be asked how you want your Linux kernel and rootfs to
be configured. Initially, I chose <code>Mediatek Ralink ARM</code> as the <code>Target System</code>.
About 24 hours later, I realised that that had been a mistake as I couldn't
manage to get any images generated without a load of compilation errors.
Confusingly enough, when compiling for a Mediatek platform, for <code>Target System</code>
you should choose <code>Ralink RT288x/RT3xxx</code>. This in turn enables you to choose
from various Mediatek subtargets, in the case of the Ubiquiti EdgeRouter X you
choose <code>MT7621 based boards</code>. Having done that, there will be a <code>Target Profile</code>
specifically for this router. Now this feels a lot more reassuring than my
earlier option where I couldn't choose subtargets or a profile.</p>
<p>Having ran <code>make -j3 V=s</code> (verbose compilation with 3 workers) I went into
<code>bin/ramips</code> and found an image for my router! But, it's the same sysupgrade
image that was available online, I still don't have the factory image I was
looking for. Some thinking and exploration of the options in <code>make menuconfig</code>
later, I realised what I needed to do. The factory images are different from
the sysupgrade images in that they combine the kernel with a filesystem
toghether, this is also called <code>initramfs</code>. Under <code>Target Images</code>, select
<code>ramdisk</code> and leave the compression on lzma as it is. When doing another
compilation run now, you end up with the factory images in addition to the
sysupgrade image.</p>
<h2>Installing OpenWRT</h2>
<p>Now I needed to find a way to actually get OpenWRT on the router. There are
likely multiple approaches to accomplishing this, but I went with what I
believed to be the path of least resistance. I spotted the router to have just
two small screws and decided to remove these. After this, the casing opens
right up without breaking any stickers and as such this shouldn't affect your
warranty. Low and behold, the pin headers for a serial connection are easily
spotted and better yet: they are already populated! I grabbed my Adafruit-style
USB to serial converter cable and hooked it up as per the pinout described on
the OpenWRT device page. I launched the <code>screen</code> utility, set the baudrate to
57600, and I was awarded with a working serial connection. I have not come
across many devices where it was this easy to set serial up.</p>
<p><img alt="Hooking up a serial connection to the router" src="/images/erx_serial.jpg" /></p>
<p>Powering on the router now it becomes apparent that it is using U-Boot as a
bootloader for its Linux-based EdgeOS. The following output shows this, and
also an interesting addition in the form of some custom pre-implemented boot
procedures:</p>
<div class="highlight"><pre>============================================
Ralink UBoot Version: 4.3.S.0
--------------------------------------------
ASIC MT7621A DualCore (MAC to MT7530 Mode)
DRAM_CONF_FROM: Auto-Detection
DRAM_TYPE: DDR3
DRAM bus: 16 bit
Xtal Mode=3 OCP Ratio=1/3
Flash component: NAND Flash
Date:Jan 27 2015 Time:17:52:09
============================================
icache: sets:256, ways:4, linesz:32 ,total:32768
dcache: sets:256, ways:4, linesz:32 ,total:32768
##### The CPU freq = 880 MHZ ####
estimate memory size =256 Mbytes
#Reset_MT7530
Please choose the operation:
1: Load system code to SDRAM via TFTP.
2: Load system code then write to Flash via TFTP.
3: Boot system code via Flash (default).
4: Entr boot command line interface.
7: Load Boot Loader code then write to Flash via Serial.
9: Load Boot Loader code then write to Flash via TFTP.
default: 3
</pre></div>
<p>Option 4 presents you with a classical U-Boot prompt and allows you to fiddle
with the environment and run any supported commands. I was curious about option
1 though. This option claims to use TFTP to load an image from the network into
RAM and then boot that image accordingly, a perfect approach to trying out an
image without having to make any changes to the data present on the Flash
memory.</p>
<p>I placed the generated initramfs image
(<code>bin/ramips/openwrt-ramips-mt7621-ubnt-erx-initramfs-kernel.bin</code>) in the
directory that's hosted by the TFTP server on my LAN and connected the router's
<code>eth0</code> port to this LAN. I then proceeded to powercycle the router so I could
try out the boot option of interest. My second attempt succeeded, pressing the
number <code>1</code> before U-Boot has printed out its choices helps significantly. Now
I was presented with a short wizard asking for the required connection and
image details:</p>
<div class="highlight"><pre>You choosed 1
0
1: System Load Linux to SDRAM via TFTP.
Please Input new ones /or Ctrl-C to discard
Input device IP (172.16.3.212) ==:192.168.2.199
Input server IP (172.16.3.210) ==:192.168.2.104
Input Linux Kernel filename (vme50) ==:openwrt.bin
netboot_common, argc= 3
NetTxPacket = 0x8FFE55C0
KSEG1ADDR(NetTxPacket) = 0xAFFE55C0
NetLoop,call eth_halt !
NetLoop,call eth_init !
Trying Eth0 (10/100-M)
Waitting for RX_DMA_BUSY status Start... done
ETH_STATE_ACTIVE!!
TFTP from server 192.168.2.104; our IP address is 192.168.2.199
Filename 'openwrt.bin'.
TIMEOUT_COUNT=10,Load address: 0x80a00000
Loading: checksum bad
checksum bad
checksum bad
Got ARP REPLY, set server/gtwy eth addr (70:5a:b6:b4:24:a1)
Got it
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
##############
done
Bytes transferred = 2731102 (29ac5e hex)
NetBootFileXferSize= 0029ac5e
..Erasing NAND Flash...
ranand_erase: start:80000, len:20000
.Writing to NAND Flash...
done
Automatic boot of image at addr 0x80A00000 ...
## Booting image at 80a00000 ...
Image Name: MIPS OpenWrt Linux-4.4.6
Image Type: MIPS Linux Kernel Image (lzma compressed)
Data Size: 2731038 Bytes = 2.6 MB
Load Address: 80001000
Entry Point: 80001000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
No initrd
## Transferring control to Linux (at address 80001000) ...
## Giving linux memsize in MB, 256
Starting kernel ...
</pre></div>
<p>Perfect, everything worked as intended and the OpenWRT factory image started to
boot! Before continuing to flash the sysupgrade image, I had a quick peek at
<code>/proc/mtd</code> to find out what partition layout OpenWRT has decided on for itself.
This layout mostly matched the one used by EdgeOS, with some names being
different and the exclusion of the SPI Flash partition and the <code>ALL</code> partition.
All in order, so I used <code>wget</code> on the router to retrieve the sysupgrade image
that I hosted with <code>python -m SimpleHTTPServer</code> and stored it in <code>/tmp</code>.
Following this I ran the <code>sysupgrade</code> tool:</p>
<div class="highlight"><pre><span class="gp">root@OpenWrt:/tmp#</span> sysupgrade -v /tmp/openwrt-ramips-mt7621-ubnt-erx-squashfs-sysupgrade.tar
<span class="go">Cannot save config while running from ramdisk.</span>
<span class="go">killall: watchdog: no process killed</span>
<span class="go">Watchdog handover: fd=3</span>
<span class="go">- watchdog -</span>
<span class="go">killall: telnetd: no process killed</span>
<span class="go">Sending TERM to remaining processes ... dnsmasq ubusd logd netifd odhcpd ntpd </span>
<span class="go">Sending KILL to remaining processes ... </span>
<span class="go">1+0 records in</span>
<span class="go">1+0 records out</span>
<span class="go">Unlocking kernel2 ...</span>
<span class="go">Writing from <stdin> to kernel2 ... </span>
<span class="go">Volume ID 0, size 11 LEBs (1396736 bytes, 1.3 MiB), LEB size 126976 bytes (124.0 KiB), dynamic, name "rootfs", alignment 1</span>
<span class="go">Set volume size to 244682752</span>
<span class="go">Volume ID 1, size 1927 LEBs (244682752 bytes, 233.3 MiB), LEB size 126976 bytes (124.0 KiB), dynamic, name "rootfs_data", alignment 1</span>
<span class="go">sysupgrade successful</span>
<span class="go">[ 81.060000] reboot: Restarting system</span>
</pre></div>
<p>Success! The router continued to boot the default option 3 and this time round
OpenWRT booted from Flash. Contrary to the initramfs image, the UBIFS on the
Flash got mounted too now and this gives you a nice and spacious RW root
overlay. Mission accomplished! Now remains one important task, and that is
to update the OpenWRT wiki with the information I have found during this little
excercise.</p>
<h2>Resources</h2>
<p><a href="https://wiki.openwrt.org/toh/hwdata/ubiquiti/ubiquiti_edgerouter_x">OpenWRT techdata page</a><br />
<a href="https://wiki.openwrt.org/toh/ubiquiti/ubiquiti_edgerouter_x_er-x_ka">OpenWRT device page</a><br />
<a href="https://forum.openwrt.org/viewtopic.php?pid=299587">OpenWRT forum topic</a> </p>Making your own QRP magnetic loop antenna2015-12-02T21:40:00+01:00Derechotag:sector5d.org,2015-12-02:making-your-own-qrp-magnetic-loop-antenna.html<p><img alt="The finished magnetic loop at its optimal location" src="/images/magloop_window.jpg" /></p>
<h2>Prelude</h2>
<p>Not very long ago I returned from having spent a year in Aberdeen in Scotland
while following a university course there. Just before going, I obtained my
radio amateur license as I was getting more and more interested in how radios
work and excited about the idea of making radio-related equipment. I knew in
advance that the local hackerspace over there was toying with amateur radio as
well, so this seemed like the perfect time to get into it. During that year
I've been involved in numerous radio-related activities and projects, some of
which I intend to describe on this blog.</p>
<h2>Indoor HF operation</h2>
<p>Right, on to the matter at hand. Living in accommodation provided for by the
university introduced a significant challenge for me if I wanted to operate on
HF. I did not have any real way to put an antenna outside nor did I have an
option to route a cable from outside to inside, so I was restricted to indoor
antennas only. That didn't stop me from eventually buying a second-hand mobile
HF radio (an Alinco DX-70, should you want to know), and I was keen to make the
best out of the situation and at least try something out. From one of the kind
space members I borrowed a QRP antenna tuner. I've experimented with many
lengths of wire in different orientations, but whatever I did the reception
would be poor and transmissions would cause significant interference (my
computer keyboard came to life for example).</p>
<p>I looked for alternative antenna designs online and discussed my challenging
situation with other local hams, which led me to look into the magnetic loop
antenna. This type of antenna is a lot smaller than its more popular
alternatives and is also a lot less efficient. However, it is much less prone
to noise from local electrical equipment, and should outperform other
compromise antennas due to its high Q factor. Being surrounded by other
students with laptops, gaming consoles, TVs, phones and tablets, reducing the
noise level appealed to me.</p>
<h2>Constructing the magnetic loop</h2>
<p>The magnetic loop is fairly simple in its design and there are various ways to
feed it. I will not go into detail about its design as plenty of others have
explained this much better than I could already. At the end of the article
I will list some resources that have given me the information I needed to
make this antenna.</p>
<p>In my situation, I used aluminium tubing of 6 mm (and 8 mm for bridging two
tubes) for the radiating loop, and I chose to feed it by using a smaller
coupling loop made of solid core electrical wiring. While aluminium was perhaps
not the most ideal choice, the tubes were locally available, they were cheaper
than copper, and they were light and thus made for a more portable antenna. The
air capacitor was gifted to me.</p>
<p>Determining the loop size was simple, I chose a diameter just under the height
and width of my one bedroom window so that I could put the loop behind it.
Various formulas and calculators for magnetic loops are available online and
with my chosen diameter it seemed I should be able to cover the 20 metre band
and perhaps a few lower bands, depending on the used air capacitor and
tolerable efficiency.</p>
<p><img alt="The insides of the pattress box" src="/images/magloop_pattress.jpg" /></p>
<p>Last but not least, something had to keep the loop in place and house the air
capacitor. The local hardware store did not offer a huge choice in project
boxes, but I did however find cheap but sturdy pattress boxes and matching
blank covers. These turned out to be ideal for this antenna.</p>
<p><img alt="The magnetic loop disassembled for portable use" src="/images/magloop_disassembled.jpg" /></p>
<h2>Result</h2>
<p>I was positively surprised by the performance of the antenna. It turned out
that I was able to tune all the amateur radio bands from 15 metres down to
60 metres with the air capacitor I used. On the lower bands however, the
decreasing efficiency became noticeable and I generally stayed within 15 to 30
metres.</p>
<p>My radio is capable of outputting 10W or 100W, or if an internal switch is
flipped, 5W or 50W. I could hear sparks flying between the plates of the air
capacitor at 50W, but 10W did not cause any issues. At this power, I've made
over a hundred QSOs on this antenna. My furthest QSO with this setup was with
N2LD in New Jersey in the US. Not bad for such a small antenna on my desk in
front of the window if you ask me.</p>
<p>In the end I have to conclude that if you are operating in very limiting
circumstances like I was, the magnetic loop may be the antenna that will get
you on the air. Not just that, with some persistence you'll even work some DX.
If you do have an option to put something outside, even if it is just a long
wire out the window to a nearby tree, then that will likely be a better bet.
However, each situation is unique, so experiment!</p>
<h2>Resources</h2>
<p><a href="http://www.g4ilo.com/wonder-loop.html">The G4ILO Wonder Loop</a><br />
<a href="http://www.66pacific.com/calculators/small_tx_loop_calc.aspx">Magnetic Loop Antenna Calculator</a><br />
<a href="http://www.nonstopsystems.com/radio/frank_radio_antenna_magloop.htm">80-20 Mag Loop</a> </p>SNES mod with one switch (50/60Hz + enable/disable lockout)2013-02-25T22:10:00+01:00Derechotag:sector5d.org,2013-02-25:snes-mod-with-one-switch-5060hz-enabledisable-lockout.html<p><img alt="Modded PAL SNES" src="/images/snesmod_completed.jpg" /></p>
<p>I've been the owner of a modded PAL Sega MegaDrive (Genesis in the US) for a few months and am very happy with it. When you have a modded MD, you can choose the display frequency (50/60Hz) and language (english/japanese). These two choices form three region-specific settings: Europe, US and Japan. There is one unused combination. A lot of tutorials show you how to get the job done using two switches, but there's also <a href="http://mdpal60.net/wiki/megadrive/regionmod/start">this neat one switch solution on mdpal60.net</a>.</p>
<p>Very recently, I've purchased a PAL SNES. Since I wanted to be able to play on 60Hz on the SNES as well, I went looking for a mod again. Similarily to the MD, there are two options that provide two choices. The first is the display frequency (50/60Hz) and the second is whether or not to enable the region lockout chip. The latter option is only needed for playing non-PAL games, which you can do once you're running on 60Hz. Some games however have a check builtin and won't work when the lockout chip is disabled. That is why you want to control this setting as well.</p>
<p>The vast majority of the mods I found require two switches. I have seen a solution where a chip from a PAL game cartridge is hooked up inside the SNES to fool it into always thinking there's a PAL game attached. This would require only one switch but I wasn't comfortable with that mod as I've read it doesn't cover 100% of the games either and I like having the option of going to a stock configuration.</p>
<p>Let's take a look at the four possibilities that these two options provide:</p>
<ol>
<li>50Hz, lockout enabled</li>
<li>50Hz, lockout disabled</li>
<li>60Hz, lockout enabled</li>
<li>60Hz, lockout disabled</li>
</ol>
<p>Scenario two seems to be unnecessary to me; you're only going to run PAL games on 50Hz and they will work with the lockout chip enabled since you have a PAL SNES. So we can get rid of that possibility. Now this is beginning to look a lot like the MD mod, perhaps we can use a single three-state switch here as well?</p>
<p>I've used the following two pages for research:</p>
<ul>
<li><a href="http://www.gamesx.com/importmod/snes5060.htm">gamesx.com</a></li>
<li><a href="http://www.mmmonkey.co.uk/console/nintendo/snes-switches-1.htm">mmmonkey.co.uk</a></li>
</ul>
<p>After reading these, I've come up with the following diagram which uses a double pole three state switch:</p>
<p><img alt="Switch diagram" src="/images/snesmod_diagram.png" /></p>
<h2>The mod</h2>
<p>Confident that my plan would work, I began working on my SNES the next day. While I've had a few years of soldering experience, getting the IC pins off the PCB still proved to be challenging. You have been warned. I ended up with my SNES working in one go and below I'll show you how I've done it.</p>
<p>Before you begin taking apart your SNES, please make sure you know what you're doing and discharge the SNES by turning it on after it has been disconnected from the power.</p>
<p>I won't go over the specific details of how you should solder wires to the necessary pins on the IC's, <a href="http://www.mmmonkey.co.uk/console/nintendo/snes-switches-1.htm">mmmonkey.co.uk</a> covers this really well already. Follow that guide to get your wires to the ICs sorted but skip the parts that involve the switches. You should end up with the following four wires:</p>
<ul>
<li>PPU1 pin 24 & PPU2 pin 30</li>
<li>Lockout chip pin 4</li>
<li>5V (O of 7805)</li>
<li>GND (G of 7805)</li>
</ul>
<p>Here is how my SNES looked after having attached the wires to the chips:</p>
<p><img alt="Wires soldered to the pins of the chips" src="/images/snesmod_chips.jpg" /></p>
<p>Now find a nice spot for the switch, I put mine on the back. Make the necessary holes in the SNES case and screw/glue your switch in place. In the diagram, a jumper wire and a resistor cross the two different poles of the switch. I soldered these first, as you can see here:</p>
<p><img alt="Jumper wire and resistor soldered to switch" src="/images/snesmod_switchbegin.jpg" /></p>
<p>Continue by soldering the four wires that you've prepared to their appropriate pins on the switch:</p>
<p><img alt="Everything soldered to switch" src="/images/snesmod_switchcompleted.jpg" /></p>
<p>And that's it! You can test your SNES out before assembling it back toghether, but do it with caution as the PCB is not well secured at this point. Don't touch any components either.</p>
<h2>PAL vs NTSC</h2>
<p>Running games on 60Hz also gets rid of that ugly border on the top and bottom of the image, as I show you below. Game running on 50Hz (PAL):</p>
<p><img alt="PAL Super Mario" src="/images/snesmod_pal.jpg" /></p>
<p>After switching to 60Hz (NTSC) while the game is running:</p>
<p><img alt="NTSC Super Mario" src="/images/snesmod_ntsc.jpg" /></p>