• View the parts list
• Download the schematic Requires ExpressSCH software.
• Download the PCB Requires ExpressPCB software.
• Download the Firmware This will make the device a repeater. It currently works in half-duplex only.
  • This a very simple repeater. Whatever comes in one interface is echoed out the other interfaces. I realized some bugs with the repeater image while I was working on the router code. This version of the repeater does contain those bugs.
• Download the Router code This will make the device a router.
  • The router will respond to ICMP echo request. But does not perform any other ICMP functions.
  • It does perform proxy arp.
  • It has a very simple arp table.
  • It supports local networks for which it is the router.
  • It supports a route configured on a network, such as a default gateway.
  • It can send log messages to a syslog server.
  • It has a route cache to speed up processing.
  • To configure the router: A Perl script interprets a rule file and generates a rules.c file that you compile with the firmware.
  • It currently works in half-duplex only. It might work in full-duplex, but I have not spent much time with this yet.
  • I'm still reading the Router RFC 1812. I do have to say, it gets quite boring after about the first 60 pages.

Today, I replaced the 2.32 kOhm resistor with 2.7 kOhm and tested the board. The board works as well as the first one did. I have a photo of this new board at the bottom of this page. My first board had two wires on the top to patch an over-site on the pcb. This time, I ran those on the bottom of the board. The PCB design available on this site does not have this problem.

Update: Oct 7, 2009 I made a second device using almost identical components. I had a few problems until I realized I had not grounded pin 19 on the SN74ALS241AN. This is fixed in the PCB above. I used three recently purchased ENC28J60 chips, but they are still using revision 4 code. This means I will have to replace the 2.32 kOhm RBIAS with 2.7 kOhm resistors. I will do this tomorrow.

Update: Oct 4, 2009 I made many modifications since my last update.

• The datasheet for the ENC28J60 specifies an external 2.32 kOhm, 1% resistor attached from RBIAS to ground. However, I found that my chip is Rev 4. The Errata for this version recommends a 2.70 kOhm, 1% resistor. I found some 2% at a local electronics store and replaced them.
• I still had a noticeable number of dropped packets. I scanned the code and added a few checks for MACIsTxReady an made sure the WritePointer was set correctly.
• I really needed a way to know what was happening. I did not plan a UART interface for this version and there is only so much information you can get from 7 LEDs. So, I added syslog support. In most of my testing, I used only interface 0 and interface 2. So, I made interface 1 send data to a syslog server. This configuration options is now part of my rules.txt file.
• I added a function to send the ENC28J60 revision number to the syslog server. I also added a function to send the number of packets queued in the receive buffer. I noticed that the buffer was full when the packets were lost. This means I need to get the packets out of the buffer faster.
• The buffer on the ENC28J60 is 8K. The max RAM on the PIC18F4620 is 4K. I increased the PIC's buffer to 1520 bytes. This took a good chunk of memory, but it would allow an entire packet to be transferred in one chunk.
• This did speed things up quite a bit, but still not enough. I considered improving the crude routing algorithm, but decided to make a route cache instead. The routing algorithm is executed on the first packet. Then the routing information is saved and indexed by the source and destination IP address. The speed up was considerable!
• I still wanted an indication of whether packets were lost. Creating a syslog entry on every packet is quite verbose. The ENC28J60 has an interrupt pin. I included a connection for this on my PCB, but had never used this feature. I read the data sheets and wrote some code and now have a syslog message written when there is packet loss due to RX buffer space constraints.
• Conclusion: For my definitive test, I decided to see if I could stream from YouTube the song "White and Nerdy". The buffer remained full! There were not hiccups. I consider this a success.

  I looked to see if there were any chips that had more RAM. Unfortunately, the better options are in the PIC32 series. Additionally, there is a new Ethernet chip the ENC424J600/624J600. Both of these are surface mount chips. I would need to dive into surface mount electronics and get an upgraded programmer. This would be a $1000 dollar investment. I was considering a MIG Welder for my next toy. Now, I will have to think about this for a while.

Update: Sep 29, 2009 I did some performance tests. The device is slower than a 10 Meg Ethernet hub. I'm not sure what is limiting the speed. I'm currently experimenting with buffer sizes, and reading the data sheets.

Update: Sep 28, 2009 I added some comments and continued to review the Router RFC.

Update: Sep 27, 2009 After a couple weeks of study and development, I made the device route IP traffic. The code needs quite a bit of cleanup and improvements. I'm using less than half of the available programming space. It looks like there will be much room to add new features. The next version of the hardware will probably contain an RS232 terminal port and maybe four Ethernet ports. For now, my focus will be on code cleanup and speed.