Wednesday, September 2, 2009

Converting a non navigation 2006 Prius with an OEM factory nav unit

It has been a long time since I dealt with automotive stuff. Last time I did anything that can be considered major was a few years back. Stuff I did before, in no particular order:

  1. Took all the insides of a 1995 Honda Civic "EG" from Japan, and assembled them all to my friend's Philippine made Civic. I had to redo all the electricals (Japan's steering wheel is on the right, Phillipines is on the left). I basically took the Philippine harness and "merged" in the Japanese harness. It was more than making it mirror image because the engine was in the same orientation on both cars. The Japanese model also had a lot more features that was not released outside of Japan and I tried to the best of my abilities to get them all to work. The drawback is, that car now has a 180Km/h speed limit (something required by law in Japan, but you're not going to really find any spot to even approach this speed anyway).
  2. I tried to rebuild a Nissan CD17 diesel engine. I learned a lot from this, and one of them is if the shop manual calls for a machine shop to do something, do NOT try to do it by hand. I also converted a Nissan B12 with Japanese parts similar to the above procedure. The original car had manual transmission, non power windows/steering. All of which I replaced with Japanese parts. The only "weird" thing is the master power window switch has the "auto" switch on the wrong side. This car does not have the 180km/h limit. (not that it will ever get to that speed)
  3. I have assisted in a few more procedures similar to the above, but unlike the above where I did everything myself, I just did some of the work. Mostly following a schematic and making the wires work. One of them was a total conversion (the whole care was from Japan).
We recently got a 2006 Prius. There are only 2 variants sold here in Australia, the base model with "nothing", and the "I-Tech" model with "everything".

Having used it for a few months you realize that it's a bit hard to find a good spot to attach a 3rd party navigation unit. The windscreen is tilted at an angle such that if you attach it near the bottom, it will be beyond your arm's reach (plus it will look so small you couldn't even make out the writing)

So what I want to do is attach a factory nav unit and make it appear on the built in multifunction display. From the fairly large amount of reading I have done, this has never been successfully performed.

Many people also shared with me what they know (so I don't repeat other people's mistakes). One of them was Steve, who told me that:
  1. I need a screen from a Nav model, because there are extra PCB's inside that are not on the non-Nav model.
  2. I would need steering wheel controls from a Nav model.
  3. I would need the mic that goes to the overhead console
  4. I would need the radio with the external amplifier (JBL)
  5. I would need the wire harness from a nav model as the non-Nav model does not have the wires.
  6. I would need the GPS antenna.
  7. I would need the Nav computer and the disc for my location.
The steering wheel controls and the nav computer arrived. It came with the mounting brackets. This unit came from under the driver's seat in the US. I still have to look under the seat in the Australian model and see if it is still under the driver's seat (right) or if they just left it in the left.

Anyway. First step is to construct connectors. I took some DB9 shells and cut up the flat surfaces with a dremel. I then poked the pins into the nav unit's port and epoxyed them to the pieces of the shell. The results weren't very pretty at the moment, but hopefully no one is really going to be taking a peek under the seat.

This is the connector after one row is in place:

Once I got one connector (the one for the display) all done, it's time to hook it up to my commodore 1040s monitor. This will give me a clue whether I should proceed or if I am wasting my time.

The left connector in this picture is the RGB, the one on the right has power (I used an ATX power supply, fed 12v to +B and ACC)


I tried to see if I could eject the nav DVD.

Ok I'm beginning to feel more confident that I could actually pull this off... Let's see how it looks like on my TV ... just for fun... I used an RGB to component converter (that I actually constructed for my Apple IIGS) that is not shown in the picture, and the composite cables on the left is unrelated and goes to a different device

Since I don't have the MFD yet (or rather, I am not ready to take the dash apart) I have no easy way of pressing the "I Agree" button. So that's how far it gets. Plus I don't have a GPS antenna so if I went ahead and attached it to the car right now, I won't really be able to see anything.

I have some free time at the moment and I was very curious to see what will happen if I went ahead and attached it to the car. After going through priuschat and reading the many "stereo removal" guides (such as this one by Chris Dragon ), I went down to the car park to figure out how accurate they are (my steering wheel is on the right side, all the guides I've seen are for cars with the steering wheel on the left). Except for the fact that the "power" button is on the rightmost vent, everything else is just mirror image of the guides (down to the location of screws and clips).

Since I have no plans of leaving it permanently installed at this time, I just dumped all the equipment on the passenger foot area.

I then hooked up only the wires needed for the display, plus the communication lines.

I also needed to power it up. There is the plug that goes to the clock. It conveniently has all the signals I need (batt, acc, gnd). I hooked up the batt and acc to the clock plug, but decided hook up the ground in the spot the 10mm hex bolt previously went:

Moment of truth. Hit the power button:

Note that it has used my display settings and the background is now blue instead of the default green background
Now that I have the touch screen hooked up. Let's see if pressing the "I Agree" button does anything... Success:
Since I have no GPS antenna and that I'm 6 basement levels underground, I won't be getting any GPS signals. It defaults to some location.

The INFO button also now displays several new icons that wasn't there before:

While all the stuff is removed, I took this opportunity to install the steering wheel controls. I disconnected the 12v battery first (something recommended when working near SRS components). waited 5 minutes then proceeded to remove the existing steering wheel controls.

I then carefully unclipped the cable tie for just the right side controls. It looks like they used the same number of wires too.
Then I hooked up the controls with the nav buttons:

And the good news is, it actually works. Pressing the voice button beeps the speaker (and then does nothing because I haven't got a mic). The phone buttons don't do anything, probably because I don't have bluetooth. Info button cycles through the energy screen and the consumption screens. Map button shows the map.

I have left the steering wheel controls in place. I have removed the nav system and reassembled the dash. I will probably do some more tests when I get more stuff in.

Screen finally arrived!! Along with the antenna!! I immediately installed both. After which I am able boot the US disc and go into the hidden menu (the one under volume). From here I chose "loading" and changed it to "Australia". It then goes back to the "please insert correct map disc" screen. Ejecting the US map disc and inserting a locally supplied "whereis v15" dvd that I borrowed caused the loading screen to appear. It looks like this is going to work.

These are pictures on how the system currently works.

Screen still off:
Turn on the key:
That's really great. All my fears that the MFD will have units in miles are for naught: (click to enlarge)
I hit the "menu" button:
Then press on the "I agree" touch button:
The DEST button works too:

That's all for now. I still have to connect the reverse line (I am having a hard time looking for it). I also have to get an overhead console with a mic so I can use the bluetooth. Sadly I do not think the australian software supports voice control :(. Pressing the voice control button on the steering wheel does nothing. It used to beep when I had the US maps disc running.


I have finally located the reverse wire. There is nothing connected at the point where it's supposed to split it up for the nav unit (probably because it's a non-nav model). I have instead, traced and finally found the wire that leads to the back of the car to turn on the reverse lights. This was well hidden behind a panel on the driver's (right) side near the accelerator pedal.

After hooking this up, I also found the wires that led to the overhead console. I connected 3 wires: Mic +, Mic - and MACC. These went straight to the back of the MFD into M14.


I have received my overhead console from a with-nav unit. It does contain the Mic and the Mic amplifier. After hooking it up for a quick test last wee, I found out that it did ... NOTHING. The bluetooth hands free doesn't do anything. I then went back to the schematics for another round, and my continuity tester just to make sure all the wires from the overhead console, to the MFD, and then to the nav unit are all correct. They all checked out, but then, what's this? There's an extra wire connected to nowhere. It was pin 3 of M14 from behind the MFD. The schematics say SGND (signal ground) to instrument panel Brace. I was thinking: "No, that couldn't be it." Most grounds in automotive parts are connected to the chassis. The MFD had a metal case bolted to the chassis, and I had assumed this was also linked internally. Well, I ASSUMED WRONG, and that IN FACT, WAS IT. After connecting pin 3 of M14 with a wire to an exposed part of the chassis, the mic finally worked.

What now remains for me to do is to wrap the wires into neat bundles. Some of the cables for the nav box should be fished under the carpet. I also need to place the GPS antenna somewhere, preferably close to where the original one went. At the moment I sticky taped it just behind the MFD. I should also fish the cable under the carpet through the center console. I also got an auto dimming mirror that's supposed to automatically darken the mirror when the car behind you is shining bright lights at you at night. I know the correct wires needed for it, but I'm not sure they are all available near the overhead console area. I think this will be the same as the Mic, the wires would be there, but they are not connected anywhere.

Monday, August 17, 2009

Network Bogons

bogon - /boh'gon/ [by analogy with proton/electron/neutron, but doubtless reinforced after 1980 by the similarity to Douglas Adams's "Vogons"] 1. The elementary particle of bogosity (see quantum bogodynamics). For instance, "the Ethernet is emitting bogons again" means that it is broken or acting in an erratic or bogus fashion.

2. A query packet sent from a TCP/IP domain resolver to a root server, having the reply bit set instead of the query bit.

3. Any bogus or incorrectly formed packet sent on a network.

4. A person who is bogus or who says bogus things. This was historically the original usage, but has been overtaken by its derivative sense

If you've spent any time responsible for networks you've probably come across Team CYMRU's network bogon lists before. Basically it's a list of source networks which you should never see on the public internet. Either because they were not yet allocated, reserved by IANA for specific uses or were defined and reserved by RFC's that had been adopted as standards.

The Team CYMRU Bogon List is here,

With IPv4 address space exhaustion about to hit most of those bogon networks are fast being allocated. Worse still many previously reserved networks that were never intended to be allocated will be.

I've already had a situation in which despite receiving emails and otherwise maintaining an awareness for new allocations I missed a new allocation before a legitimate customer wound up with an IP in it and tried to use my services. It has become a pain in the ass updating your bogon lists at this point and it makes more sense I think to identify the networks that will continue to be bogons once there is no more IPv4 addresses to allocate. Particularly when you're not a large ISP acting as a transit AS and you already run a very secure network.

My upstream ISP's are fairly good at filtering the bogon sources themselves, and my ingress ACL's are specific enough and the general security of internet facing servers is good enough that even if someone does use an unallocated source IP to attack your network in the immediate future I'm not particularly concerned.

You can rely on your upstream ISP/s to filter them for you, and if you can utilise Team CYMRU's route server you can automate the process of filtering and removing new allocations using BGP. However if you don't have trust your ISP and have no BGP capability, for whatever reason, you may need to statically filter them.

I log at a warning level so that if I do start seeing a lot of invalid traffic I can start to investigate and possibly tell those upstream ISP's that they need to filter it or may have a misconfiguration of some kind.

Wikipedia has a good overview of the current situation with linkage to RFC documents so you can consider for yourself which networks you'd like to filter.

And the below is a self documenting example for PIX/ASA with a group for placing any malicious sources that annoy you enough to block them.

object-group network RFC-1918
object-group network RFC-2544
object-group network RFC-3171
object-group network RFC-3330
object-group network Nasty-Gnomes
description People we don't like.
network-object host x.x.x.x
object-group network Bogons
group-object RFC-1918
group-object RFC-2544
group-object RFC-3171
group-object RFC-3330
group-object Nasty-Gnomes
access-list outside-ACL-Inbound line 1 remark Deny unwanted source hosts
access-list outside-ACL-Inbound line 2 extended deny ip object-group Bogons any log warning

Friday, August 14, 2009

Apple IIc plus 240V modification

I have recently acquired an Apple IIc plus. This is the fastest "stock" Apple II made by Apple Computer. It was only available for a short time, and only sold in the US.

Because of that, they only have a 120v power supply available. I initially plugged it into my 240v to 120v transformer. It's a bit inconvenient (because it is both big and heavy) and I don't really like lugging the transformer around. At first I thought there might be a provision for a switch inside... nope, no such luck. The other option would be to substitute an ATX power supply. Mark referred me to this:

It looks ok.. and it *might* even fit into the IIc plus case... but it looks more like the size of a IIe power supply.

My intention was to keep everything looking "stock". The power supply had to stay internal with no power bricks, etc. I also considered using James Littlejohn's LittlePower Adapter IIc+:

and placing a picoPSU-60WI and a 12v supply inside, but I am unsure I will be able to fit everything inside. I may reconsider going this route later on if I ever decide to make the IIc plus a truly portable battery-powered computer.

I then did a random google search and found this site:

Jorge has posted schematic diagrams and how he modified his IIc plus to allow it to be powered directly from the 240v mains.

This is the power supply after I took it out of the IIc plus.

This is the space it used to sit in.

Unfortunately, The replacement capacitor I got was too tall. It would fit just exactly but I did not want the metal shell pressing down on it. So I decided to mount the capacitor sideways

This is the replacement capacitor beside the original one:

This is how it looks mounted:

The electronics shop I get all my parts from (Jaycar) did not have the 20v 5watt zener diodes that Jorge used. I thought that instead of 7 20v ones, I could use 10 15v ones.

7*20v=140v (Jorge's mod)
10*15v=150v (My substitute)

This should give me Vab of 190v (which means I don't really have to replace the capacitor)... But as my luck would have it, they only have 9 remaining units of the 15v zener diodes.


Giving me a Vab of 205v.

So I took a pcb and soldered the diodes on the solder side (that way I don't have to worry about insulating the other side from hitting other high voltage stuff). This is how it looked:

Before closing the lid, I cut off a corner of the PCB because the yellow wire is a bit stretched. I also placed a piece of clear tape on the cover in case one of the legs touch the top of the case.

Then I tested it with a multimeter and the voltages looked right (I know. I should not power up a switching power supply with no load... but.. but it's only for a little while). Then hooked it up back to the IIc plus, and it fired up without a problem. (no smoke, nothing)

The unit does get warm in the area near the diodes. I have left it on running a BASIC program drawing random stuff on the hires screen. It's a bit warmer than what I would like but seems to be acceptable. If you do a lot of disk access (continuously cataloging the disk, it tends to get hotter).

Overall I'm happy with the way this turned out. The IIc plus still looks stock on the outside and I'm now able to plug it in anywhere without lugging the oversized transformer around. I have kept the jumper I took off and the capacitor in the event I want to restore it back to default.

Tuesday, August 11, 2009

PIX or ASA Stateful Failover Configuration

I subscribe to RSS feeds from some 20 or more Cisco centric blogs, many of them maintained by CCIE's or those studying for CCIE's.

Occassionally someone posts a PIX/ASA failover configuration example. Generally I feel they fall short of the mark in providing a detailed secure and real-world example on how to configure stateful failover.

This configuration below is as complete as it gets however. And it is relevent to both PIX and ASA devices. More so for ASA as they do not have a serial interface that was used for PIX failover once upon a time in the networking dark ages.

The configuration below uses two physical interfaces on each firewall. It's seems somewhat a waste however Cisco does recommend doing so in various documents. I've not had a problem mixing both failover communication and traffic state replication on a single interface. To use just one interface remove the references with "failover-state" on the line.

Take note however, some people tend to use the Management0/0 interface on ASA firewalls as the failover or state link. It can be OK to use the 10/100mbit Man0/0 interface for failover communication as this does not utilise much bandwidth. You should however avoid using it for failover state however. Particularly on ASA models with Gigabit interfaces as state replication requires the lowest possible latency and zero packet loss to work reliably and avoid having your firewalls fail over randomly or lag behind in maintaining traffic state when they do fail over for the right reason. With multiple Gigabit interfaces simply replicating connection state information for that the traffic being permitted through the firewall can exceed the capacity of a single 100mbit interface.

And if you're not using Man0 properly for out of band management of the device you really should be!

I've also used 169.254.x.x link-local addresses on the failover and failover state links. As PIX and ASA do not have a VRF/private routing table concept they do add routes to the IP addresses you configure to their routing table. Worse still they do seem to actually route/accept traffic for the IP's you configure on failover links/state interfaces from your other interfaces.

You would of course need to accept the traffic in an ACL but it's not uncommon for some people to permit all RFC-1918 addresses to particular services. Not a good idea.

169.254.x.x are supposed to be link-local self-configuration addresses and any decently configured intermediary router should route them to null0 so provided you don't accidentally permit them in an ACL there should be no way for anyone to try and talk to your firewall on those IP's.

! ---------------------- FAILOVER CONFIG PRIMARY ------------------------ !
failover lan unit primary
failover lan interface failover Ethernet3
failover link failover-state Ethernet4
failover key <%FAILOVER KEY%>
failover replication http
failover interface ip failover standby
failover interface ip failover-state standby
failover lan enable
int Eth3
no shut
int Eth4
no shut
! If you're running a 7.2 image or newer the following is also recommended.
! It will change the CLI prompt to indicate the configured type and state of the device you're connected to,
! ie if your firewall's hostname was FW0 the prompt would look like,
! FW0/pri/act#
! Indicating it's configured as the primary and it is currently active.
prompt hostname priority state
! ---------------------- FAILOVER CONFIG STANDBY ------------------------ !
! Everything else will sync over from the primary
failover lan unit secondary
failover lan interface failover Ethernet3
failover link failover-state Ethernet4
failover key <%FAILOVER KEY%>
failover replication http
failover interface ip failover standby
failover interface ip failover-state standby
failover lan enable
int Eth3
no shut
int Eth4
no shut

Saturday, February 28, 2009

Hacking a DVI cable to build an ADC to DVI converter

In the last post, I mentioned that my powermac G5 came with a video card that had 1 ADC and 1 DVI out. I wanted to hook up 2 screens to it and do not have an ADC monitor. (besides, the 25v line intended to power the ADC monitor is under-spec in my homemade power supply.)

Well, I took out a standard DVI cable and carefully opened up one end:

The pins on this single link DVI-D cable are not complete, and Apple used some of the non-existent pins on the ADC side of things. I had to move 3 pins (1, 9 and 17) to the area in the middle (4, 12 and 20). I drilled holes using a PCB drill and pulled out the pins with long nosed pliers. I then placed them (pins and all) on the ADC port of the video card and applied some epoxy to the area around the hole (the holes were too big).

This is after only one pin is moved:
This is after all 3 pins were moved.

I then carefully used a good combination of shrink tube on the wires so that nothing will short.

After testing this to verify that it works, I epoxied the black part back on to the shell. Now I have 2 screens hooked up to the Powermac G5.

Friday, February 27, 2009

Rebuilding a Powermac G5 power supply using ATX partsI

I have recently acquired a dead Powermac G5. The previous owner said that he brought it to the service center and its going to cost ~$600 to get it a new power supply, and that was all that it needed to be able to run again.

Well after getting the unit home. The first thing to do is test it without doing anything. Who knows, it might actually NOT be broken. In goes the plug... Pressing the power button results in... nothing.

So next step would be disassemble the unit. This is the intake fan:
This is the side of the unit with the cover off:
These are the covers for the heatsink

Because I did not have the correct service manual for this unit, I took the logic board out before taking out the power supply. I realized later that I only needed to take out the lower CPU to accomplish this (and yes I did take it out again ... but more on this later). I also read somewhere that there is supposed to be a cover on top of this power supply that is now missing, the service center must have forgotten to put it back. Some of the cables were also disconnected, again, my guess is that the service center did not bother to plug it back in as it is broken anyway.

This is the power supply. It is the biggest computer power supply I have ever seen. The middle connector is as big as a standard 24 pin ATX connector.
This is what's "under the hood" of the power supply.
This is the label stating how much Amps is needed by each line. A standard 600W ATX supply should satisfy these values. The only thing missing is the 25Vsb line. From what I have gathered, only the ADC out (for special apple displays) would use this. At this point I was not too concerned about the 25Vsb line.
This is the whole power supply's internals:

After the past experience with blown capacitors, I was hoping this is another case... No such luck. Poking around with my voltmeter revealed that the fuse was blown. I have a spare 250V 10A fuse that i quickly put in. Who knows, it may just be the fuse. I replace the fuse and then plug it in... poof: smoke comes out and the fuse is blown again.

A Careful inspection of the power supply board reveals that there are switching transistors whose legs are melted, there is also a crack on the board, and that there are more surface mount IC's at the bottom side of the board:

Some of the IC's are burnt too much to be able to read the writing on them. Ok... I was going to try to "component-level" repair this one, but at this point, it looks like it would be more feasible for me to substitute an ATX power supply.

After getting a 550W power supply from a nearby computer store and testing this with a spare PC motherboard and verified everything working, I cut all the wires coming from it, and desoldered the cables from the original G5 power supply board. I connected everything to the corresponding voltage but left out the 25Vsb.

This is how it looked after the operation:
I used shrink tube to insulate the individual wires to keep it clean (electrical tape would leave a sticky residue). After double and triple checking my connections with the voltmeter, I am ready to plug it in. Before I put all the screws back I should test it and see if it actually would work:

So, it's the moment of truth. Plug it in and press power button... Power supply fan runs... red LED lights up on motherboard... but no startup chime. Repeat... same...

Of course (duh). There is no RAM. (double duh). After installing a pair of 1Gb sticks of PC3200 DDR memory (from my iMac G5):

Pressing the power button now gives the easily recognizable apple startup chime, or as a good friend calls it, the "jeng" sound. That's all I needed to hear, out comes all the cables, out comes the 2nd CPU... put the power supply and everything else back on...
And it all works. Both CPU's detected, About this mac says it's a "Dual 2 GHz PowerPC G5". I did notice it was a bit noisy. My wife described it to a coworker as "it's as if there is an airplane about to take off". After doing some more reading, I think I may have put the processors back the wrong way (swapped the 2). The logic board seems to "remember" the CPU ID of what was there before, and keeps a thermal profile stored in non volatile memory. This thermal profile would be specific to that particular CPU. If you were to replace any of the CPU's (or like what I did, swapped the 2) the logic board was programmed to "play it safe" and spin the fans (all of them) at full speed. I have 2 options, take the CPUs off and swap them back (no way). Or run what is known as "thermal calibration". Running thermal calibration took about 30 mins (about 15 mins for each processor), after which the fans are running at their normal speed now.

After all that I used the computer for a few days, and noticed that the power LED was not lighting up. It wasn't lighting up either during sleep (it's supposed to look like it's "breathing"). After taking out the front panel connectors and power switch, testing the LED reveals that there is nothing wrong with it, nor with the cables connecting it to the logic board. The only thing that could be wrong would be, apple must have used the 25Vsb line for the LED. I found a 24V switchmode power supply at a local electronics store, and after taking out the power supply again, I was able to put it inside (there was lots of room left). This power supply came with a voltage adjustment knob which I changed to 25V with no problem. This unit is only rated for 25W so as long as I dont go about plugging in an ADC monitor, I should be fine. After plugging it in, The LED now works.

I used the DVI connector to connect it to my monitor. I wanted to hook up 2 monitors, but the other connector was ADC. Well... as this is a different topic, I will write about it another time.