This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/baseband-devel@lists.osmocom.org/.
Thatsit thatsit at gmx.chHi 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