Interesting research! I write software to talk through FTDI devices all the time (not by choice) so this is definitely something to keep in mind in near-realtime applications: Keep the packets at 2048 bytes or less, or you lose half of your effective bandwidth. Thanks for posting!
I would guess that there might be a [particular laptop or motherboard configuration that might implement the USB in a more optimised manner. But that's almost like the days of the PCW bench tests where computers were tested against each other in ridiculously specific manners. RS485 is definitely a nice rugged industrial data transfer system. Quite fascinating in its own right. (Although the more technical details of the 120 ohm characteristic impedance are quite frankly not very entertaining at all.)
+bigclivedotcom I had a problem with some VTR which used 485 remote control. One day, someone replaced one of the units and we started getting intermittent errors. It turns out that all of the VTRs had their termination switches ON and they were looped together. It worked with four switches on (30 ohms!) , but five caused problems. We turned all of them off and used an external terminator on the last one in the chain.
+Chris W That's the thing about 485 - when done right it's bombproof, but can "sort-of" work if not wired correctly. First thing to do on any 485 setup is an end-to-end resistance check for opens & wrong termination.
+mikeselectricstuff +1 to the soft-of work part, especially on a multi-drop network! We use 485 nearly exclusively in our products at work. Sometimes though (usually user error) the network is terminated/polarity inverted/transceiver mode set incorrectly and the issue pops up in a random location on the bus. Agree with checking resistance, found the point of issue quickly that way. Fun when the data is corrupted/inverted due to one of the two lines being O/C or S/C.
Love your vids. Been subbed for two years or so, and if I may, can we have some more year down vids please sir? I would send some stuff if shipping wasn't off the scale from NC to you! Thanks to Mike and his electric stuff!
Revisiting this video after a very long time, since You said it's a driver issue, I'm curious whether there would be the same problem in a Linux/BSD environment. I'll definitely keep that in mind when dealing with these.
+mikeseletricstuff some ealier usb 3.0 boards use different chipsets for the USB 3.0 and USB 2.0 ports maybe that,s a way to go around the port limits?
Great video as always. Looks like Easysync may have gone out of business in December 2021. A shame as their equipment is very good. Ebay may be the only source now.
I was just wondering why you up loaded a wide screen (16 x 9 ish) video within a 4 x 3 frame? Thought it was odd, you being a tech kind of guy! interesting vid however.
I am using SPI interface of FT2232H, it is very nice, and can get 30Mbps with no problem ( good thing is DMA can get 65535 space, just like maximum packet size. And it use bus quite well. For very short packets it can be 10KHz repetition rate, and for longer packets, it will shift more data. And only at small packets, bus utilization is not very efficient, but with larger packets, it is very good. But yes, it's for single point communication, unless you will change SPI to differential signaling or something... FTDI just released USB 3.0 with parallel interface i think i will give a try
Did you try using a different pair of ports? I know a lot of PCs these days actually have multiple USB controllers, so if you got one of those on each of them you'd have better results.
Maybe if the USB size limit is a common issue (OS rather than motherboard, for example) then perhaps you could use a client-server setup, either with a PC hammering data across Ethernet to its clients or using Raspberry Pi, etc. as a smart "here's a big fat packet, now chop it up and bang it out to your USB ports" device.
did you try a multi-threaded (/multi-process) application? I wouldn't be too surprised if your write call is blocking just that thread... It could possibly permit even better parallelism with the sub-2k packets, and would likely bring down the inter-port latency with larger packets too... unless the FTDI driver is genuinely badly implemented.
Please update the description to be more clear/specific. What is the source (PC with software?) and what is the sink (µC with RS-232)? What are you measuring where? Many things only got clear as I watched the video. "Shoving multiple data streams out of one USB port to UARTs" Would be more descriptive.
Looks to me as if an IT guy programmed that part. This is the exact same way a lot of routers handle packets larger than a particular size (i.e. just drop)
I suspect the Linux drivers won't have these issues. I think for windows a libusb based driver tuned to handling multiple ports via better scheduling/multiple threads might be the way to go.
Ftdi_sio and usbserial modules? As you say, these are probably good as I think they are open source. Libftd2xx.so is most certainly closed and most certainly buggy.
+mikeselectricstuff : The driver should implement scatter/gather I/O (Vectored I/O) ; It's quiet common in driver/kernel world with hardware buffer limitation. From the user point of view the driver will split the big packet in 2k chunk, and send it to the hardware. Quite easy to implement, shame on FTDI driver guys.
This is why you EE guys really need to get into Linux. Often these edge cases are much better handled - or if not at least there is an opportunity to do something about it.
+Gooberslot Everyone has different experiences and needs and all the various OS fans get too hung up on which OS they think everyone should have to use/not use. I love Linux for servers and some development work and use it heavily for such, but it is nothing but headaches for me on the workstation front so I am not terribly fond of Linux for workstation use nor would I try to make my less than tech savvy family use Linux workstations. Plus constantly needing to emulate Windows under Linux can be a headache as I have a lot of commercial software and drivers that do not have comparably effective Linux counterparts and I have better things to do than reinvent the wheel and author all the code required to replace them. To each their own!
+Ethan Poole Yeah - but you seem rather hung up on your non-support for Linux. It's only a suggestion. Mike can consider the suggestion, and look into it - or not. Of course a transition would require some changes to workflow - that's one of the costs of trying something new, and why many people dual-boot. I'm just saying that many people - myself included have benefited in their projects from having access to the inner workings of their OS. Which is why I'm saying it's a useful tool to have on hand.
+Gooberslot At 7:36, he appears to be using LibreOffice Calc - so he clearly doesn't have too big a problem with it. Also it's nice to see non-Linux users gaining awareness of the need for LibreOffice over Apache OpenOffice.
Serial bus utilisation: 102%, you should patent that one :)
Interesting research! I write software to talk through FTDI devices all the time (not by choice) so this is definitely something to keep in mind in near-realtime applications: Keep the packets at 2048 bytes or less, or you lose half of your effective bandwidth.
Thanks for posting!
+Jac Goudsmit Bear in mind the packet sizes may be different for the non high-speed USB devices
Very Clear Instruction indeed. Successfully shoved lots of data out of multiple USB port. Thank you.
+Virulent I have done many Clear Insctruction videos so far, and can see very fast if Instructions are given clear or not:)
I would guess that there might be a [particular laptop or motherboard configuration that might implement the USB in a more optimised manner. But that's almost like the days of the PCW bench tests where computers were tested against each other in ridiculously specific manners. RS485 is definitely a nice rugged industrial data transfer system. Quite fascinating in its own right. (Although the more technical details of the 120 ohm characteristic impedance are quite frankly not very entertaining at all.)
+bigclivedotcom I had a problem with some VTR which used 485 remote control. One day, someone replaced one of the units and we started getting intermittent errors. It turns out that all of the VTRs had their termination switches ON and they were looped together. It worked with four switches on (30 ohms!) , but five caused problems. We turned all of them off and used an external terminator on the last one in the chain.
+Chris W That's the thing about 485 - when done right it's bombproof, but can "sort-of" work if not wired correctly. First thing to do on any 485 setup is an end-to-end resistance check for opens & wrong termination.
+mikeselectricstuff +1 to the soft-of work part, especially on a multi-drop network! We use 485 nearly exclusively in our products at work. Sometimes though (usually user error) the network is terminated/polarity inverted/transceiver mode set incorrectly and the issue pops up in a random location on the bus. Agree with checking resistance, found the point of issue quickly that way. Fun when the data is corrupted/inverted due to one of the two lines being O/C or S/C.
Excellent video, Mike. You should make more of these design vids - I love them! Thanx!
Another excellent experiment and video. Thanks.
like your scope. It makes test easy when you have the right equipment
Love your vids. Been subbed for two years or so, and if I may, can we have some more year down vids please sir? I would send some stuff if shipping wasn't off the scale from NC to you!
Thanks to Mike and his electric stuff!
Revisiting this video after a very long time, since You said it's a driver issue, I'm curious whether there would be the same problem in a Linux/BSD environment. I'll definitely keep that in mind when dealing with these.
+mikeseletricstuff some ealier usb 3.0 boards use different chipsets for the USB 3.0 and USB 2.0 ports maybe that,s a way to go around the port limits?
Do you call the write functions in parallel threads or sequentially? I figure if you spawn one thread for each endpoint, it all goes fast again.
Great video as always. Looks like Easysync may have gone out of business in December 2021. A shame as their equipment is very good. Ebay may be the only source now.
I was just wondering why you up loaded a wide screen (16 x 9 ish) video within a 4 x 3 frame? Thought it was odd, you being a tech kind of guy! interesting vid however.
+Michael Beeny 4:3 is standard, youtube seems to like 16:9 for no clear reason, so youtube's fault?
+Michael Beeny Getiing video right is notoriously tricky
+Michael Beeny Just reinstalled Vegas and settings are messed up - not got around to sorting it out yet
+Michael Beeny Yawn, who cares. You can see the content, so no worries.
+TheChipmunk2008 I wouldn't say 4:3 is standard at all anymore.
I am using SPI interface of FT2232H, it is very nice, and can get 30Mbps with no problem ( good thing is DMA can get 65535 space, just like maximum packet size. And it use bus quite well. For very short packets it can be 10KHz repetition rate, and for longer packets, it will shift more data. And only at small packets, bus utilization is not very efficient, but with larger packets, it is very good.
But yes, it's for single point communication, unless you will change SPI to differential signaling or something...
FTDI just released USB 3.0 with parallel interface i think i will give a try
i saw in a comment you use sony vegas for your video's
what are your computers specs?
Did you try using a different pair of ports? I know a lot of PCs these days actually have multiple USB controllers, so if you got one of those on each of them you'd have better results.
Maybe if the USB size limit is a common issue (OS rather than motherboard, for example) then perhaps you could use a client-server setup, either with a PC hammering data across Ethernet to its clients or using Raspberry Pi, etc. as a smart "here's a big fat packet, now chop it up and bang it out to your USB ports" device.
did you try a multi-threaded (/multi-process) application? I wouldn't be too surprised if your write call is blocking just that thread... It could possibly permit even better parallelism with the sub-2k packets, and would likely bring down the inter-port latency with larger packets too... unless the FTDI driver is genuinely badly implemented.
or try setting the non-blocking flag!
have you played with usb3.1? i think you can address more ports than usb2.0
Please update the description to be more clear/specific.
What is the source (PC with software?) and what is the sink (µC with RS-232)? What are you measuring where? Many things only got clear as I watched the video.
"Shoving multiple data streams out of one USB port to UARTs" Would be more descriptive.
As rs485 is dmx, why not try ethernet to dmx node style setup? Curious rather than saying its better.
+ceecrb1 10:26
+stonent yeah like an idiot I typed before watching the whole video....
Looks to me as if an IT guy programmed that part. This is the exact same way a lot of routers handle packets larger than a particular size (i.e. just drop)
Just so I'm sure I understood, you just want to send lots of data to multiple serial ports through *one* USB connection on the PC, right?
I suspect the Linux drivers won't have these issues. I think for windows a libusb based driver tuned to handling multiple ports via better scheduling/multiple threads might be the way to go.
The Linux d2xx drivers have other, un-fixable bugs... :( faulty implementation of FT_GetQueueStatus being the main culprit.
Hugh Frater I meant the driver in the kernel.
Ftdi_sio and usbserial modules? As you say, these are probably good as I think they are open source. Libftd2xx.so is most certainly closed and most certainly buggy.
It didn't make sense he was whispering... turns out I heard him through my headphones and not speakers. Late evening. -_-'
+DarkInsanePyro Mike whispering makes a good evening :)
megabaud
Who *says* that, lol.
+unlokia I do. I also say "nineteen-kay-two baud" and "nine-kay-six baud". If you have to say that often, you tend to keep things short.
+mikeselectricstuff : The driver should implement scatter/gather I/O (Vectored I/O) ; It's quiet common in driver/kernel world with hardware buffer limitation. From the user point of view the driver will split the big packet in 2k chunk, and send it to the hardware. Quite easy to implement, shame on FTDI driver guys.
This is why you EE guys really need to get into Linux. Often these edge cases are much better handled - or if not at least there is an opportunity to do something about it.
+fractureforce He said on the Amp Hour that he doesn't think too highly of free software. :(
+Gooberslot Everyone has different experiences and needs and all the various OS fans get too hung up on which OS they think everyone should have to use/not use.
I love Linux for servers and some development work and use it heavily for such, but it is nothing but headaches for me on the workstation front so I am not terribly fond of Linux for workstation use nor would I try to make my less than tech savvy family use Linux workstations. Plus constantly needing to emulate Windows under Linux can be a headache as I have a lot of commercial software and drivers that do not have comparably effective Linux counterparts and I have better things to do than reinvent the wheel and author all the code required to replace them. To each their own!
+Ethan Poole Yeah - but you seem rather hung up on your non-support for Linux.
It's only a suggestion. Mike can consider the suggestion, and look into it - or not. Of course a transition would require some changes to workflow - that's one of the costs of trying something new, and why many people dual-boot.
I'm just saying that many people - myself included have benefited in their projects from having access to the inner workings of their OS. Which is why I'm saying it's a useful tool to have on hand.
+Gooberslot At 7:36, he appears to be using LibreOffice Calc - so he clearly doesn't have too big a problem with it. Also it's nice to see non-Linux users gaining awareness of the need for LibreOffice over Apache OpenOffice.
Wouldn't it be easier to use ethernet? USB is such a chore, and Ethernet usually gives userspace code access to basically the raw data.
Yeah but they give you kind of a shakey serial interface (you can't /actually/ do full-duplex)
Well I meant as an interface to the RS485, not replacing it. They make ethernetRS485 adapters already.
+rfmerrill
Did you read Richard's reply at all?
First.