This is not a 'huge problem', but it is a 'huge annoyance'.

After all I wouldn't want to show someone the Project and have them see the Corruption only for me to say, 'Yeah, that happens'...

It is something that I would like to get remedied.

For my mind I am down to 4 things left to try that could be the problem.

I would be grateful for any input regarding whether there are other or better things to try.

I have a Project Running. One of the things that the project does is output data VIA the Serial Port.

From time-to-time there is 'data corruption' on the Serial Output Data Stream.

The corruption can be a couple of characters, or it can be dozens of characters.

I am using the Nerdkits Prolific USB-Serial 5v Adapter...

The project is running on a board I soldered together.

I have an AC-DC Adapter that outputs 12v. (I am not close to maxing it's output.

I have a 100uc Capacitor on the power bus.

1 - I initially thought that maybe it was a bad solder joint. I don't think this anymore because I resoldered those joints and I have NOT had any issues with anything else attached to the Micrcontroller. (Since the other things connected have MANY
MORE connections and are running with no issues, I have since discounted solder joints.)

2 - Serial Terminal Emulation was 'Tera Term', now it's PuTTY. (I think it was 'Tera Term'.) At first when I used 'Tera Term' got 'confused' every so often.
When it was 'confused' I had to use it's reset function to reset the serial port. Then it would be okay for awhile and get 'confused'.

(What I mean by 'confused' is that no valid data would come
through...)

I switched to PuTTY and that is when I 'noticed the 'data
corruption'.

I suspect, now, that the 'confusion' that 'Tera Term' had was 
initiated by the 'data corruption'.

3 - Is it 'Baud Rate'? When I was 'testing'

I used 1200, 9600, 14400, 19200, 57600...
There doesn't really seem to be much of a difference.
Corruption is still occurring.

4 - I thought maybe a bad serial ground. I was 'grounding the Prolific USB-Serial Adapter to the 14v DC Input. After thinking about it, I thought maybe I should ground it on the board I have so I did that.

No affect.

Now to the 4 possibilities...

1 - Maybe the 12v DC in is not constant. I thought about setting up another Microcontroller to monitor that, but I haven't done that yet. (I seemed to have misplaced my old 'TOIT'...)

  I may try a 'supersize capacitor', or maybe running off a 12v
  battery too just to find out.

2 - I am using an even 16mhz Crystal. So things aren't dividing evenly. Could that account for it?

  I didn't think so since there does seem at times to be dozens
  of characters that are off...

  I could probably use my nerdkits 14.7456mhz Crystal to check.

  (Although I am using other Timer Interrupts I don't think that
  any of the things I am doing would be affected by that change...)

  I have my Crystal in a socket so that wouldn't be too hard.

3 - I don't have any capacitors on the crystal?

4 - What about pull-downs on the Serial Txd from the Microcontroller?

P.S.

I have NO IDEA why 1 and 2 didn't indent right... I thought the 'tab trick' was guaranteed...

Are there more things, or better things, to try?

Hi Jim -

I read somewhere the reason the 14.7456 Mhz crystal is used is due to the fact that all baud rates are even divisors of that rate. Doing the math that seems right. I would try that option before any others.

The replacement of the crystal could definately be your issue. Your margin of error is zero with the 14.7456MHz crystal just as pcbolt stated. Because it is evenly divisable by standard baud rates. 16MHz is not and as a result you will see errors. These may be more obvious on different hardware and at different baud rates. With a 16MHz crystal, your error is anywhere from about -3.5% to 2.1% depending on baud at baud rates of 2400 to 115200bps. With the 14.7456MHz crystal the error is zero.

If you need additional speed, your best bet would be to go to an 18.432MHz crystal, it is the next fastest with a zero margin of error with standard baud rates.

If you want to see the error charts, they are in the datasheets (Table 19-12 on the revision of the sheet I have)

If you are programming the part the standard NK way, are you swapping crystals after program transfer? If not, I'm surprised your program would even make it over to the chip.

Rick

Hi pcbolt,

If you are using a 16Mhz crystal I am quite surprised you are getting any data at all across the serial port. Timings on the serial protocol are pretty sensitive.

Humberto

Hi Humberto,

I think you wanted to respond to Jim. I haven't advanced yet to building my own PCB's...yet.

Ooops, sorry pcbolt. I meant to give you credit for mentioning a good idea =).

Humberto

Actually Humberto I think I read about that idea from a post either you or Mike put up some time ago.

Hello Everyone...

I really can't take credit for the Circuit Board. (I did solder it, and some of the circuit is custom.) I purchased the board, and it had a 'breadboard portion' that I have used as well.

I do, however; plan to get some boards made once I get a better idea of what I would like.

I am not loading the program VIA the 'Standard Nerdkits Way'. I am using an Atmel AVRISP MK-II Programmer.

The Crystal doesn't seem to have an impact on this problem.

I put the original Nerd Kits Crystal back in and the problem does still exist. (I am only using the Baudrates of 9600, 19200, 38400, 57600. Mostly I stick with 38400 or 19200. But I have tested all of the ones I have listed, and the problem is mostly the same.)

I had looked at the Tables for the UART UBRRn Settings for Commonly Used Oscillator Frequencies.

I do think there is some sort of 'interference in the signal though'.

One thing I was able to do, is I put in a 'gap between each character sent on the Serial Interface'. With the 'gap there' the error rate goes down dramatically.

Now I know that the 'bit rate within the transmitted frame' is pretty much 'accurate' because the Microcontroller Generates that. (If it doesn't divide evenly that doesn't really affect the 'bit rate' it only 'affects how well the bit rate matches with perfection for a given Baudrate'.)

I am pretty sure that the Prolific USB-Serial Interface 'uses the baudrate settings' as what is 'expected' but then 'oversamples the incoming bits' which would probably take care of any minor deviations. (The AVR Microcontroller itslef has built in 2x Serial bit oversampling.)

I did put in a BIG CAPACITOR on the incoming 12vdc prior to the 5vdc regulator on my circuit board... The BIG CAPACITOR is large enough to run the board for a good 10seconds without power.

I think that effectively puts to rest the idea that it may be a 12vdc power problem from the AC/DC Adapter.

One additional thing came to mind earlier today?

The AVR Microcontroller has an 'aggregate limit' on how much power it can source. (Is that right? Or is it sink? I think it's source in this context. In any case...) I am going to alter my code to shutdown all non-necessary pins during the Serial Communications and see if that has any affect. (By 'non-necessary' I mean 'pings not necessary/required for serial communications'...)

Does your F_CPU define, UBBR Value, and Crystal speed all match? I've sent data at 115200bps and not noticed any garbage data.

Have you tried a different serial adapter - maybe one based on the FTDI chipset? Does your PC have a hardware serial port you could test with - you can add a small circuit to communicate with a "real" RS232 port. Do you have a different PC you could test it on?

Rick,

Are there any other 5v Serial Interfaces that you have used that work?

the only one(s) that I have are the Prolific USB-to-Serial Interfaces.

I've used the ones listed in my prior post as well as a max232 to a true pc serial port.

I am intending this to be the "closing post for me on this thread"...

I have come to the conclusion that the 5v Serial Interface on the Microcontroller is NOT the problem.

The 5v Serial Interface on the Microcontroller is "rock solid" as it is configured for my circuit.

I was only, initially, pursuing the Micrcontroller angle since "I made it and programmed it".

So my initial thoughts were, "that the Microcntroller was the most likely source of the problem(s)". That was why I focused on that angle to begin with.

Since the first post, and hundreds of megabytes of transfers, I have found out all that I think I need to find out on this.

What did I find out?

These things have, or can, affect Serial Error Rates for me on Windows x64...

1 - Serial PC-Microcontroller Ground is very important for stable Serial Transfers. (I knew this, and that wasn't my problem, but I thought I would throw it in...)

2 - Plugging the Computer and the Microcontroller into "different AC Sources" can be a problem. (Well not really "different AC Sources", but I couldn't think of a better way to phrase it. I have had some problem(s) if the Computer was plugged into a UPS and/or Surge Protector when the Microcontroller power supply was plugged directly to the AC Outlet.)

3 - In Windows 7 x64 under the 'Advanced Power Management' there is a USB Option for 'USB Selective Suspend Setting'. This setting hould be "disabled".

4 - For me on the laptop there is a difference between the USB v1.0 and the USB v2.0 Ports. USB v2.0 works much better 'over a period of time', but it has 'streaks of errors that are longer than the USB v1.0 ports'.

5 - I have 3 Powered USB Hubs. ALL of them either increase the error rate or essentially make the Prolific USB-to-Serial Adapter unusable.

6 - Rebooting the laptop with the Prolific USB-to-Serial Adapter plugged into the laptop as well as the Microcontroller helps significantly in reducing the error rates. (On my 2 desktops it makes no noticeable repeatable difference.)

7 - Adding an 'inter-character gap' in my Serial Data helped considerably on the laptop. It helped a little on the desktop. (There was not very much change in the error rates based on Baud Rates I have been using.)

My Final Worst Case Error Rate Averages are:

__ "Errors/1000 ASCII Characters" "Errors/1000 ASCII Lines" ___ (NOTE: For these purposes ASCII Lines are about 20 bytes line each.)

Laptop USB v1.0 __"43"__"14"

Laptop USB v2.0 __"<1"__"7"

Desktop(s) USB v2.0 ___"<1" "5"___

P.S. All of my timing values in the Code are set appropriately.

There was no noticeable difference in errors rates for me between the "standard Nerd Kits Supplied Crystal vs my 16mhz Crystal". (Of course the 'timing values had to be changed appropriately for both' to function at all.)

I am pretty confident now that the issue(s) are on the PC side of things somewhere. Exactly where?

I am not sure exactly where the problem(s) are, and since I am pretty satisfied with the current errors rates for now I don't see any need in delving further into this for me. (I would PREFER 0 error rate, but what I have is usable for now.)

I have used 3 different Terminal Programs.

Eventually I switched to a Java Program using the RxTx Library and ".dll's" that I created. (Mainly for learning and flexibility reasons...)

All of the Terminal Programs I used seemed to be about the same, as far as error rates go, except for Tera-Term. That didn't work well for me at all.

Using the 'AVRISP MK-II Programmer' you can talk with the ATMEGA168 via it's ISP pinout, and you should have error-free communication up to 2Mbps, under Windows 7, 64-Bit, using WinAVR. I've also used it (same rate) under 32-bit Windows XP.

If you are having a communication problem, I strongly recommend (because this is a known issue) that there is a driver conflict, or corruption.

BM