If you have stumbled upon this blog entry, then you have encountered the above error message while trying desperately to connect to another networked computer on your home/office network. There are a tremendous number of people encountering the same problem, so you are not unique in your quest to locate the ‘right’ solution.

I’ve been working the same problem on my folk’s office network and it took me over 15 hours to find the ‘right’ solution for them. I will now attempt to iterate how I solved this issue. Please pardon me if I stray.

Symptoms:

1. Computer ‘A’ is unable to connect to computer ‘B’.
2. Laptop ‘C’ is unable to connect to computer ‘B’.
3. Computer ‘B’ CAN connect to computer ‘A’ and laptop ‘C’ (files can be copied to and from both machines).
4. All three computers are able to connect to the internet through the router and the DSL modem.

The Network:

1. Computer ‘B’ is connected to the network using its built-in Ethernet card to a Linksys 4-port Wi-Fi Router.
2. Computer ‘A’ and Laptop ‘C’ are connected to the same router wirelessly (using Wi-Fi).
3. All computers are running WinXP Pro with SP2.

My Solution:

1. Update the firmware on the Linksys Router if it hasn’t been done already. You’ll need to download the latest firmware from Linksys and save it. Update the firmware by firing up your browser and entering the address of the router into the address bar. Of course, this will need to be done from a computer that is physically connected to the router.
2. Uninstall ‘File and Printer Sharing for Microsoft Network’ from ALL of the computers on the network. Control Panel -> Network Connections -> Local Area Network -> Properities. Highlight ‘File and Printer Sharing for Microsoft Network’ and press ‘Uninstall’. It doesn’t matter if you aren’t using the Local Area Network to connect to the network, this will uninstall file and print sharing from all networking devices.
3. Instead of performing a ‘soft’ reset of the Router (like I had tried many times before) or turning it off, waiting 5 minutes and turning it back on… break out the installation CD and allow the CD software to walk you through installing the initial stages of your network. Remember to keep track of the Workgroup name you want all your computers to associate with. If your network is partly ‘Wi-Fi’, then remember to keep track of the SSID of the network.
4. Share whichever folder you want each computer to share with each other on the network. Since we uninstalled ‘File and Print Sharing….’, this will fire-up its installation wizard and walk you through the process.
5. Double-check each computer and verify that each has a different name, but the same workgroup. Control Panel -> System -> Computer Name. Click on ‘Change’ if either of them need to be altered.
6. Restart each computer.
7. Connect to the Router through a directly connected PC and verify that your computers now are listed in the DHCP Client table. Pour through your Router’s manual if you don’t know how to do this. Both wired and wirelessly connected computers should be listed.
8. Finished… that is if everything before went smoothly.

Things to Remember:

1. Don’t worry about keeping the router’s DHCP on and using that part of its functionallity. Only unless it is completely necessary to give each computer its own static IP, should you even consider disabling your router’s DHCP.
2. Enable NetBIOS on TCP/IP? What? This could bring forth many a security issue that you aren’t prepared to deal with. Leave that setting alone and probably in its DEFAULT setting. Besides, I have only seen this implimented on a network using Active Directory and was performed to allow SMS to work.
3. If you are having to use a password or log into a networked computer and are NOT using a Peer-to-Peer network, then why are you networking these computers in the first place?
4. Mapping a Shared Folder as a Network Drive has some benefits. It can be tedious to keep things straight when setting it up, but the visibility factor tends to outweigh the initial grunt-work.

5. IRPStackSize in the Registry? I’m not entirely convinced this will work, but I did find one of the computers that did NOT have this entry. I added it through HKEY_LOCAL_MACHINE\ SYSTEM\ CURRENTCONTROLSET\ SERVICES\ LANMANSERVER\ Parameters\. There shoud be an entry for IRPStackSize. The default is 15 (in Decimal), but if it doesn’t exist, then create a new DWORD entry called IRPStackSize (remember that registry keys are CASE SENSITIVE). After creating the entry, locate [Base], clicking on the radio-button to select [Decimal]. Type in ’15′ into the [Value Data] field and click [OK].

6. I have never run into a problem with any anti-virus programs and networking computers, so I doubt that the current products get in the way of your ability to make your network WORK. Not that it couldn’t happen, but worry about this ONLY if the problems began AFTER updating your virus protection software.
7. Don’t mess with the Windows XP Firewall, unless you are convinced it is the root caue of your networking issues. Perhaps you MAY have accidently denied an activity you really should have accepted, but this happens rarely.
8. 3rd Pary Firewall? I’ve never used one, exceptfor the Router’s built-in firewall. Could 3rd party software cause an unintended network problem? Is the Pope Catholic?
9. Never turn off the Windows Firewall. Just don’t.

Again, the most likely culprit will be whatever software installaion, registry tweak or hardware installation you did last before the entire network went bonkers. If you can’t think of anything, update your router’s firmware and re-install the network from the ground – up. It is far better to rebuild, than to massage each computer onto the network.
I hope this helps.

The semester has wound down and now it’s time for my lab partner, Derek, and myself to build our final project using the PIC18F452. There are no restrictions on how what programming tools to use, so we’ve so far determined that we’ll be writing it all in C18.

Our final project will be based upon previous lab projects, however, instead of using a magnetic-stripe card-reader, Derek found a cheap RFID reader that we’ll be using instead. A magnetic-strip card-reader is the same type of device most people use to swipe their credit / debit cards when making ATM withdrawals or purchasing clothes at your favorite retailer. An RFID reader is similar to the ‘pass’ card machine that an elephant used to purchase cold / flu medication for his favorite zoo keeper in a recent commercial I’d seen on television. They operate in a similar way that the security turn-stiles at the local Target beep at you when the cashier forgets to remove the large plastic tag from your newly purchased t-shirt and tennis shoes. If you are a resident of Chicago, IL, you’ve seen similar RFID devices for the fast-lane of the numerous toll booths in the surrounding area.

RFID stands for Radio Frequency Identification and there are two basic types: passive and active. In order to keep RFID tags small, many of them are passive; they require no internal battery or power supply. Active RFID tags are larger, since they use an internal power source (perhaps a battery), however they have a much greater range which is beneficial in areas (like electronics toll booths) where there is an increased amount of RF traffic. Everyone has a radio in their possession and that’s how RFID devices work. They contain small antenna tuned to a specific radio frequency and when the RFID device passes within inches of its associated transmitter, the RFID devices converts the received RF energy into actual voltages and current to power up its built-in microchip. The RFID’s built-in microchip then transmits a series of digital ones and zeros that form that devices identification number. The identification number is similar to that of the average bar-code you see on the side of your box of Cheerio’s. The transmitter also has a built-in receiver, so that when it ‘hears’ the sequence of bits spat out by the RFID device, a series of actions are performed depending upon what the RFID device is used for: open a lock, log an entry into a database, return price information, charge a toll fee to a FasTrack subscriber, or set off an alarm.

Here at the University of Iowa during off hours, engineering students use a passive RFID card to gain access to the Seamen’s Center / Engineering Building. This is the kind of device that we’ll be using for our final project, which we’ll be basing around the Parallax RFID Reader Module shown in the picture above. Parallax reader is a 3″ x 2.5″ blue circuit board that uses a 2400 baud TTL serial interface. It is an ‘output only’ device that only requires a single +5VDC supply and houses an LED for a visual indication of activity.

Part of the trick with our final project will be to read the serial data from the RFID reader, while being able to output text information to a computer terminal. Since our PIC18F452 development board (shown at the top) has a single serial interface, this poses a communication problem.

How do we communicate with two devices with only one interface?

Fortunately, the RFID reader is an ‘output only’ device, while the PC terminal CAN be used as an ‘input only’ device. A typical serial (RS-232) interface has three connections (Transmit, Receive and Ground). The RFID reader will use Transmit and Ground, while the PC terminal will use Receive and Ground and they won’t be talking to each other directly. They will be talking to our PIC18F452 or listening. They won’t be doing both.

Wait. Doesn’t RS-232 use +/- 12VDC for it’s transmit and receive logic? Isn’t the RFID reader using TTL (+5V and Ground)?

Yes. But not to worry. Our PIC18F452 development board has a MAX232 chip, which will convert between TTL and typical RS-232 voltages. We’ll need to use that chip to communicate to the PC terminal, but we don’t need it to communicate with the RFID reader. Instead of routing the output of the RFID reader to the input pin to the MAX232, we’ll route it directly to the receive pin of the PIC18F452. In fact, instead of leaving the MAX232 chip plugged into our development board, we’ll remove it and mount it into a socket that is soldered into a smaller development board.

This would all be fine and dandy, but we still need the ability to program the PIC18F452. So, since we need some ‘bi-directional’ communication between the PIC18F452 and the computer in order to upload our (soon to be developed) program, we will route the Receive line from our development board to a switch so we can ‘choose’ which input to accept (the PIC programmer or the RFID Reader).

In the photograph above, you’ll see our PIC18F452 development board with the MAX232 chip removed and re-socket-ed onto a small square pc board. Although small, we’ve mounted the small DPDT switch to the right of the chip. The RFID Reader (held in the blue desk-clamp) is connected to the brown circuit board through four wires (+5V, GND, Chip Enable, and Serial Out).

Our initial code (written in C18), simply waits for an ID card to be placed flat and several inches away from the RFID Reader. Once the ID card has powered up from the Radio frequency generated by the RFID Reader, it ‘spits out’ its digital ID # stream, which is read back by the RFID Reader and sent to the serial input (MAX232) of our PIC18F452 development board. Our code re-assembles the ID # stream into 8-bit bytes, and sends the data out to the terminal, so we can determine what ID # was received.

(April 28, 2007) – Spent some time yesterday trying to incorporate code from our last several projects into this final project. We are currently trying to incorporate the 12-digit keypad, but appear to have found ourselves stuck. Typically, we print out the value of the key that was pressed back to the terminal, but when we tried this Friday it didn’t work. Plus, we found that our RFID Reader no longer worked. I’ve been working this issue this afternoon and have finally found the culprit. Simply put: WE GOT LAZY. When we determined that the RFID Reader was ready to send us data, we stupidly turned around and sent data back out to the terminal –> printf(“We got data “); This erased the contents of the buffer (holding our input data) with what we wrote back out. So, when we tried to read the contents of the buffer, it was empty. There was nothing to actually read. Talk about feeling stupid.

(April 29, 2007) – After Saturday’s fiasco, we still had more work to do with RS-232 communication. The frustrating part was the issues we were running into were not fully explained in the MPLAB C18 Manuals. The problem came from attempting to repeatedly read the ID numbers off of our RFID embedded cards (they look just like an ATM card, but blank with no magnetic strip on the back). We could read the cards MAYBE twice or three times in a row, before our C18 program would quit reading the data from the RFID Reader. We didn’t have any problems in previous labs when we were communicating via RS-232 to our PC terminal. Of course, those experiments involved serial communication at 19,200 baud. To communicate to the RFID Reader, we need so slow things down to 2,400 baud. After trying every ReadUSART, getsUSART and getcUSART command (and their variations) in the C18 Manual and tweaking the OpenUSART a hundred times, we finally hit upon the real problem: Framing & Over-Run Errors.

What are those? Well, they are the kinds of errors one encounters often when trying to dial into AOL from 30 miles outside of town. A framing error is an error in … ‘framing’. Every byte (8 or 9 bits) sent over the line has a ‘start bit’ at the beginning and one or two ‘stop bits’ at the end. A framing errors means that the receiver didn’t see the ‘stop bits’, when it expected them to appear. Conversely, an over-run error is an error that occurs when the receiver isn’t extracting the the received bytes fast enough. This means that the receiver is a little slower than the transmitter and there exists a risk that data will be lost. The RFID Reader spits out the RFID card data at 2400 baud, without regard to how fast the receiver is extracting the data. We can’t inform the RFID Reader (over RS-232) that data needs to be re-transmitted, in case the receiver suspects it has lost some information. Under NORMAL RS-232 communications, we could, but the RFID Reader is a transmit device ONLY. It won’t receive anything.

To fix this we had to dig through the MPLAB C18 Manuals to determine what the PIC18F452 does when it wants to flag a possible framing or over-run error. Unfortunately, no matter what we did, the USART_Status variable (suggested by the C18 Manuals) did absolutely NOTHING. We had to hunt down what this mysterious ‘USART_Status’ variable in the C18 source code to find the ACTUAL status bits this variable was supposed to represent. We found the right status bits in: RCSTAbits.OERR , RCSTAbits.FERR and RCSTAbits.CREN. OERR is the over-run error bit, FERR is the framing error bit and CREN is the bit to toggle (set low, then set high) when either of those errors occur.

(April 30, 2007) – Derek and I hammered away at this project for a few more hours. With the rest of the code in-place. It looks like we have a completed final project. We wondered if we needed to change some of the LCD messages, but we concluded it would be easier to change the intended messages in the flow-chart. We also discussed the possibility of adding the EEPROM code, so we could add the ID card numbers & PIN numbers into non-volatile memory. It would be nice, but it isn’t necessary for our “proof-of-concept.” We’ll have to offer our final presentation on Tuesday, which should go well… as long as I don’t spend too much time ‘yaking’. Derek will probably do most of the presentation, while I will field questions during the Q&A session afterwards.

(May 2, 2007) – The final presentation went well and our T.A. was VERY impressed as i put our project through its paces. Every-other word from his mouth was, “Cooool.”

(May 17, 2007) – The Spring Semester is over and grades are out. Our final project must have been a hit with both our instructor and the T.A. (teaching assistant). Somehow, after doing poorly on the first mid-term exam in Embedded Systems, I managed to pull an ‘A’ in that class. Here’s the PowerPoint Presentation we gave for the RFID final project. It’s been transformed into an Adobe PDF file: RFID Access Control System