JavaLaurence Posted April 26, 2014 at 02:41 PM Share Posted April 26, 2014 at 02:41 PM Can anyone briefly explain why the Tinkerforge architecture limits its USB bandwidth to 1000 64-byte messages per second? Quote Link to comment Share on other sites More sharing options...
borg Posted April 26, 2014 at 04:44 PM Share Posted April 26, 2014 at 04:44 PM It is the maximum for USB, see chapter 5.10.2 in the USB 1.1 specification "USB Clock Model": Bus Clock: This clock runs at a 1.000ms period (1kHz frequency) and is indicated by the rate of SOF packets on the bus. That means, that a PC can poll a USB device with the maximum rate of 1KHz or once every 1ms. Quote Link to comment Share on other sites More sharing options...
JavaLaurence Posted April 26, 2014 at 06:30 PM Author Share Posted April 26, 2014 at 06:30 PM Thx for the USB Spec ref (checked it.. very interesting). Apart from the source code (which I'd rather not have to consult), is there any technical documentation of how Tinkerforge uses USB ? Or rather, is there any docs on the entire comms architecture (USB and Wifi)? Sorry for being so nosy.. Quote Link to comment Share on other sites More sharing options...
borg Posted April 26, 2014 at 07:07 PM Share Posted April 26, 2014 at 07:07 PM There is no documentation of the internals (except for the source code). The protocol itself is documented here: http://www.tinkerforge.com/en/doc/Low_Level_Protocols/TCPIP.html The WIFI Extension speaks it directly, over USB we use the same payload as over TCP/IP. Quote Link to comment Share on other sites More sharing options...
Nic Posted April 28, 2014 at 09:08 AM Share Posted April 28, 2014 at 09:08 AM Remember 1000 msg/sec is a benchmark in theory, normally an operating system has to handle callbacks, events etc. from other connected hardware devices, too. TF mentioned in this matter a max frequency of around 250Hz or at least 125Hz if a robust or reliable application is needed. http://www.tinkerunity.org/forum/index.php/topic,2253.msg14892.html#msg14892 Quote Link to comment Share on other sites More sharing options...
JavaLaurence Posted April 28, 2014 at 09:41 AM Author Share Posted April 28, 2014 at 09:41 AM I think it's quite confusing to see those low numbers when, if you don't know the internals, you'd expect a TF stack to be able to communicate at much higher bandwidth. If you hear of any device that connects via USB or Wifi to a PC, then you kind of expect that device to be able to use "the most" of those transports. It's just an expectation/surprise thing... Quote Link to comment Share on other sites More sharing options...
Nic Posted April 28, 2014 at 10:04 AM Share Posted April 28, 2014 at 10:04 AM Should I remove my comments and hints to prevent any confusion on customer side ? I added links to mining the internals/explanation easier: http://en.wikipedia.org/wiki/Nyquist%E2%80%93Shannon_sampling_theorem Quote Link to comment Share on other sites More sharing options...
borg Posted April 28, 2014 at 10:04 PM Share Posted April 28, 2014 at 10:04 PM @JavaLaurence: We do get the absolute maximum out of the USB protocol. If you use callbacks and configure them to 1ms and there are no other USB devices that are using the bus and your PC is fast enough you will get 1000 messages per second from one single Bricklet. More is not possible. I am not sure what you are expecting? @Nic: You are confusing things. The other discussion is about the "tick_task" and calculating things inside of it. You can get the full 1000 messages per second from every Bricklet that can produce this much data (i.e. every IO Bricklet (IO4/16, Industrial DI, ...) and every Analog Bricklet (Analog In, Amient Light, ...)). Quote Link to comment Share on other sites More sharing options...
Nic Posted April 29, 2014 at 10:24 AM Share Posted April 29, 2014 at 10:24 AM @borg Well, from the customer perspective it brings me nothing if a system (OS + TF stuff) can reach "theoretically" the limits of 1000msg/sec and 1 bricklet on 1 brick as the only USB stuff in a system isnt really typical. A lot of people have asked about how fast and reliable they can expect acquisition of data eg. detect encoder or scan signal if its fall or rise. I assume it could be more interesting to complement discussion by your mentioned and committed benchmark of 250hz. BTW, can y give some examples in practice from last couple of month and known projects of customers where the limit of 1000msg was reached on a regular basis ? Quote Link to comment Share on other sites More sharing options...
borg Posted April 29, 2014 at 08:48 PM Share Posted April 29, 2014 at 08:48 PM BTW, can y give some examples in practice from last couple of month and known projects of customers where the limit of 1000msg was reached on a regular basis ? I am not sure what you mean, i just tried it out and used a Master with several Bricklets and configured a Sound Intensity Bricklet callback to 1ms. I got 1000msg/second on the first try with lots of USB devices connected to my normal work PC. It is really not hard to get 1000 messages out of a stack. There are of course lots of Bricklets that can't produce this much data, but if they do it is not hard to get it transferred to the PC. The other way around it works too. If you use an IO4 and toggle the value every ms you get a pretty good 500Hz signal. I have tried that several times before. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.