Hi
I also want to share my experience with osmocom and USB-serial cables..
My conclusion is clear that it is not a matter of physics (electrical) but of timing constraints.
- both chips (cables) Prolific and FDTI show more or less the same behavior regarding successful firmware loading
- after loading the firmware none of the cables ever made any problems (thanks to Harald's HDLC layer:-)
- Prolific result in smaller buffer sizes used (768) than FTDI (4096)
- Prolific is noisy, that means if the plug is not connected to the phone you will see endless random characters received my osmocom
- I made some tests on tree different platforms and 3 different mobiles (C123, C139, C155) and the Prolific cable so far: 1. very smal PC with Ubuntu 10.10 Server 2. Vmware with Ubuntu 10.10 Desktop on older MacBookPro 3. VirtualBox with Ubuntu 10.10 Desktop on a new MacPro (6 cores, 6Gb ram)
- Generally I got the best results with the C155 and worst with the C123
- On the MacBookPro/Vmware I never could successfully load any firmware on any phone
- On the small PC the very first try after a reboot succeeded most of the time. From then on nearly every try failed
- On the new MacPro/VirtualBox nearly every Try succeded!
Then I ordered a FTDI cable in the hope that this would solve all my problems..
- It supports none standard baudrates - thats cool
- But the firmware loading didn't work better... :-((
For me it was then quite clear that i can only be a problem of the timing.. that means the phone is simply not willing to wait so long for the next character to read..
On my small PC I started killing some of the processes I don't use right now (mysql, apache, ..) ... and oh wonder.. the firmware loading worked already much better:-))
The I commented out all printf's which printed something out during the boot-loading.. .. and wow... from then on it worked nearly 100% of the times!!
Conclusion:
If you have a powerful machine, you probably won't have any problems.. Else, we should probably think about changing the code in use during boot-load slightly.
I think that every time the osmocom executable calls select(), and thats a lot of times, the kernel probably reschedules the processes.. and through this increases the chances that there results a to big pause sending data to the phone..
Does this sound plausible?
Best regards Matthias