After letting the battery in my FT-817 go dead, and losing the DC cable for awhile, I had no trustworthy transmitter to determine a frequency offset with. I mean, was I really going to rely on local repeaters, with the FM capture effect being able to accommodate rather large tuning errors? Finally I got my power cable and did a small CW tone, but of course proximity made a defense and created multiple signals in the waterfall. Finally I found the right one, which results in a frequency correction off 1,000,014 (the unit shipped with 999,855, a 158ppm difference).

I started with WRPlus, which is recommended in the FCD tutorials, but I found the layout poor, and more importantly the program started becoming unreliable and crashing. Granted, this is running on my Acer Iconia Tab W500 (new to me, but relatively underpowered with its C-50 processor), but HDSDR seems to be doing a much better job.

Second, and a common problem, is that the FCD is relatively deaf. The FT-817 is much more sensitive in practice. The FCD has no front end filtering to speak of, and therefore is prone to de-sense in high RF environments (LA qualifies!). I’ve been trying to accomplish the same satellite receptions that I have already listed on this blog (same antenna), with no success yet. Looks like I’ll need to invest in some band pass filters…

I should also note that I am running firmware 18j. 18i was giving me periodic stuttering in the waterfall that I thought was just a CPU resource issue, but it persisted after I stripped out all background processes.

I also signed up for the FCDeveloper group (in addition to the normal FCD group), so that I could get my hands on FCHID008, since it seems to be the only controller with an option for the FCD’s bias tee. The bias tee is great because it allows me to I can conveniently use my new quadrifilar helix antenna. It is quite apparent that the antenna’s preamp is working, but I have not attempted satellite reception with it quite yet.

Lastly, while the FCD is supposed to be multi-platform, the QT based controllers simply crashed on my Macbook (running Snow Leopard if it matters), and the forays into gnu radio will have to wait for another day (and all the other applications seem far too dated to put in the dependency-hell effort).

I recently got the following prompt:
Time Machine completed a verification of your backups. To improve reliability, Time Machine must create a new backup for you.

Which meant my old backup was going to get deleted!

I disabled Time Machine while I figured out what to do. Thankfully, Garth Gillespie documented the recovery process quite well in this post.  Basically, the Mac had to perform a thorough fsck on the backup sparsebundle, and I had to change some flags in an XML file. Simple but lengthy process. I let it run overnight (on gigabit, as suggested). Thanks Garth!

• It consumes considerably more power than the WRT54G-TM it replaced, so much so that I could no longer use with my Cyberpower Phonesaver (a kind of mini-UPS that only outputs DC, designed for cordless phones) to back it up. I’ve since settled on a standard, albeit small, UPS.
• It runs a bit warm, so I placed standoffs underneath it to improve ventilation

So, the WRT54G-TM sat unused for a few months, until the rediculous requirement came about that, for a particular Nintendo DS game (Animal Crossing Wild World), I had to setup a WEP access point! Therefore, a secure and isolated guest network was necessary. A similar setup exists at my parent’s house to support the same game.

I used the following guide, along with this, with the following changes would be required to support the E3000:

• vlan2 is used as the WAN, so this guest network has to be created on vlan3
• The port assignments start with the WAN as port 0 (backwards from the WRT54G), therefore, the port furthest away from the WAN port, which will be used as the guest network port vlan3, is port 4
• The CPU on the E3000 is port8, not port 5 as it is on the WRT54G
• The init script needs to refer to vlan3, not vlan2
• The firewall script needs to refer to vlan3, not vlan2, and on the 2nd line where vlan1 is mentioned it needs to read vlan2
• The DHCP configuration needs to refer to vlan3
• The first QoS rule is anything from the vlan3 subnet is defined as the lowest priority
• Assign a static DHCP address on the main router for the guest router’s WAN address
• Forward an arbitrary range (I’m trying a mere 10) of UDP ports to guest router so said game would work.

The guest router is setup relatively close to the main, but they are separated by a couple meters in an effort to reduce interference. I used the following settings:

• Low TX power (10mW, may be reduced further)
• Ch11 (my main is channel 1, so there shouldn’t be any interference)
• It is also set to be B only (no G, no mixed)
• Basic Rate of 1-2Mbps
• Transmission Rate of 1Mbps
• No telnet, ssh, and wireless web admin access
• remote admin access with https enabled
• MAC filtering to only allow the Nintendo 3DS in question
• Static DHCP address assigned to 3DS
• 3DS’ IP address is setup as the DMZ

Today I heard:

• AO-51 voice repeater
• CO-57′s CW beacon
• HO-68′s CW beacon
• COMPASS-1′s CW beacon
• CO-65′s CW beacon
• RS-22′s CW beacon

• ISS packet (2m)
• ARISAT-1 voice tlm (2m)
• RS-30 CW beacon (70cm)
• HO-68 CW beacon (70cm)

Interior:

• FT-817ND all mode HF/VHF/UHF transceiver (5W) w/ CAT cable
• BD-35 VHF/UHF amplifier
• 1GHZ VIA mini-ITX computer, equipped with 12V Powerpole outlets

Anyways, I took this as an opportunity to upgrade to an SSD. Grabbed an ADATA AS599S-64GM-C RT off of Newegg for $140. The advertised rates are always exaggerated, but with Blackmagic Disk Speed Test I clock in around 140MB/sec read and 110MB/sec write. Still no slouch.

Is there anything left in my Macbook that I haven’t replaced?

It also appears that in the grand march of the 2.6 branch being experimental instead of stable that the  the ide=nodma kernel flag is deprecated and not replaced by anything well documented. Disabling DMA altogether in the BIOS (even after a BIOS update) is not recognized by the kernel either – it just attempts to ascertain the DMA status of the CF card anyway and proceed to panic / delay the sequence by 30-45 seconds.

I then decided the best tactic may be in fact to just get a UDMA compatible adapter and card. The adapters are fairly prevalent, and cheap, but the cards definitely have a price premium. Not surprisingly these are predominately used by the digital photography industry so one doesn’t have to wait as the image is being written before taking the next shot.

These finally arrived, and must to my surprise did NOT resolve the problem. I’m going to chalk this up to a motherboard quirk; its not the first time this Jetway J7F2WE1G board has been temperamental.

Thankfully, I did finally find a working kernel flag, albeit intended only for debug purposes (oh well). Just add ide-core.nodma=0.0 (0.0 means primary master, 0.1 means primary slave, 1.1 is secondary master, etc).

Now I can get back to what I actually want to use this computer for (mailserver, time machine backup, & APRS station).

• Poor battery charging algorithm. Battery is shipped flat and the firmware has a low cut-off voltage which makes it stop charging early (read: minutes, not hours, of runtime). Workaround is to force multiple charge cycles by power cycling the base every 15 minutes or effectively do the same thing with a script commanding the Rovio to drive forward (off the charging base) and immediately drive back on it. If the battery is altogether shot, I can always get an off-board charger and maybe a new battery.
• Potentially poor dock charging contacts. Don’t have a good workaround yet, but since they are spring loaded they could be augmented with magnets.
• Wheel encoders dropping out. Either the emitters are degrading (which has been fixed by decreasing the current limiting resistors, at least in the short term) or the detectors are losing sensitivity (which has been fixed by replacing the entire encoder assembly, or by increasing detector intensity by decreasing the resistors). This problem exhibits itself by the Rovio as not driving entirely straight, overshooting specific rotation angle commands, and degraded (but ultimately successful) auto-docks.
• Poor on-board lighting. The camera does not perform well in low lighting conditions so installing additional lighting is an obligatory mod. Some are installed in the neck so the light follows the camera, others remain in the body, yet others are installed on the deck itself. Most use the original’s transistor driving signal to command it and tap into the Rovio’s battery, but some have used the neck’s position to drive an independent switch for those afraid to open up the chassis. These usually involve running off of different batteries.