On 10/17/2011 7:48 AM, slippyr4 wrote:
> Hi All,
>
> My current project uses an 18F45K22 to pick up some data from a serial GP=
S.
> I merge some other data in with this NMEA data and sent it out on the oth=
er
> serial port to the PC. I hold the GPS data in a ring buffer on the PIC. I=
've
> decided to use a trimble TSIP-like protocol for my data, because I alread=
y
> have a load of code written to handle this on the PC. So I have a few TSI=
P
> packet types, one for an NMEA sentence, one for my other data.
>
> The output data stream is async, 57600 baud. My pic is clocked with a 16M=
Hz
> crystal and PLL on. BRGH=3D1, BRG16=3D1 and my SPBRG value is 0x0115 whic=
h by my
> calculation results in a baud rate of 57552 which is 0.08% out. I am usin=
g a
> MAX3232 as a level converter.
>
> Now, the problem: when i connect my circuit to a (generic, chinese
> made,prolific chipset) USB->Serial converter, after a couple of minutes o=
f
> successful data streaming, the data seem to become corrupt. As in, the
> actual data received on the port is garbage. How long before this happens=
 is
> variable.
>
> Every single time, If I stop and restart my PC program, the data is OK
> again.
>
> I've cut the PC program back to bare-bones, and just had it write the raw
> received data to the disk- this data stream becomes corrupt. It's not my
> program messing up the data, it really does become corrupt on the receive=
..
>
> I then changed to a "real" serial port on my PC, and the data is fine. I'=
ve
> run the program for 24 hours, continuously, and every single byte receive=
d
> was perfect.
>
> So, there is something funny with the USB serial convertor, or my interfa=
ce
> to it.
>
> Has anyone had similar issues? or do you have some ideas for investigatio=
n?
> I should rather like my circuit to be reliable with usb-serial converters=
 as
> well as with real serial ports.
>
> thanks
>
> slip
The general theory among my Local Ham Radio Friends is that the Prolific=20
Chips have been poorly counter-fitted!
In general, even the counter-fits seem to work well when you get the=20
proper down level driver installed.
However, sooner or later, Windoze will update to the latest driver and=20
the counterfits will not work until you restore the old, correct driver.

Prolific seems to be the biggest victim but the consumer is a close second.

Other than experience I have no evidence to support this notion.
I think the problem could be resolved for us users with a rewrite of a=20
new driver that would detect & accommodate
whatever the component needs but  then needed information is not open=20
source and it is hard to justify the effort
to hack the situation when the consumer can resolve it for a few dollars=20
more!

Were I in charge of Prolific I would try for a driver that detects the=20
counterfit chip and notifies the customer.
  Although that might enable the work around easier, it would serve to=20
clean the company's public image.

I will repeat:
Other than experience I have no evidence to support this notion.

--=20
John Ferrell W8CCW


--=20
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.