Data Logging @5KHZ using the LM4f232 board

This is an interesting question! I just did similar testing on the LM3S811 with the USB transfer of a packet of accelerometer data to a PC.  The X,Y,Z data using the UARTStdio library formatted with the UART version of printf.

I used the 115200 BAUD rate. So maybe the BAUD rate should run faster or maybe slower -- maybe we have a timing issue.

My maximum transfer rate was about 3500 to 4200 samples per second depending on exact format of ASCII packet. Perhaps the next step is a "real" serial port and a set of level changers to get the RS232C spec.

Changing the "Collection rate below 125KSPS slowed the process -- setting to 500KSPS seemed to "garble" the data somewhat as the samples were not exactly what they "should have been".

The Serial via USB I wrote is interrupt driven at the LM3S811 and the PC -- so I should not be losing data.

I have a MAKE controller uploading packets via UDP -- I have tried the MEGA 2560 using UDP (Ethernet I/F) -- neither did much better.

Maybe somebody has some experience using another way.

I am considering adding an I2C interface to the PC -- or maybe SPI to move data. Perhaps that is the next step if serial and Ethernet truly cannot do this.

I am in the process of setting up the three controllers in a test bed and using the same data collection program to save the data in an SQL DB (Interbase -- Embarcadero).

Not much help -- but maybe some more thoughts to consider.

As I said, I do not know if I2C would be faster, but I searched out these products which are worth a look:

This is a USB to I2C interface -- not sure it would be faster.

http://www.digikey.ca/product-detail/en/UMFT201XB-01/768-1119-ND/3029126

This PCI to I2C you would think that this would be faster for data transfer: (430MBit)

http://www.xdimax.com/pciex/dmx10.html

Something to consider anyway.

I think the only difference between my upload and the logger is that they upload the numbers in a binary packet. Something I will be adding to my routine. As well, I will try the Serial 256K BAUD rate as that may be an issue as well -- don't see how though as apparently the ADC converter cannot keep up on my LM3S811 board.

The LM4F232 should be faster -- and it is the board I was going to buy for serious development. However, if speed is an issue regardless maybe none of these boards would work out -- if this is a general issue. Is it faster with Ethernet? So far on other boards it is no different with Ethernet -- not by my timing tests....

Hopefully the "big guns" of development expertise will weigh in with some ideas.

Please explain further your error.  

The LM4F should be able to capture the data at 5khz but it will require modifications to the code. What modifications have you made?

It sounds like the problem is in transferring the data.  Where are you trying to log the data to? The application comes with several storage options. Have you done a bandwidth calculation?  How many bits of data do you wish to transfer each second? Keep in mind the format of the data such as ASCII and any padding bytes/bits that are added to the packets. Is the bit rate of the transfer method enough?

The virtual serial port method used in the logger application to communicate with the PC is chosen for simplicity not speed.  If you need higher bandwidth a different USB device class may be better suited to your application.  

Dexter

Dave Robinson said:

Perhaps the next step is a "real" serial port and a set of level changers to get the RS232C spec.

Note that RS232C itself is only defined for up to ~20kbps.

Although most COM ports in real life do go higher, few exceed 115200bps.

Not all RS232 transceivers support high speeds.

The higher the speed, the more cable quality & length matter.

USB itself has far greater bandwidth than "RS232" - so it's not the USB itelf that's the limiting factor.

I have successfully used FTDI USB-to-serial cables at 460800bps, and they support 921600 (can't remember if I've tried that)

I have found that USB-to-serial adaptors give higher actual throughput than a real COM port at the same baud rate - unless you happen to have a specifically-designed/optimised COM port (extra-deep FIFOs, perhaps?)

Hardware flow control becomes important at these speeds...

Andy:

Interesting info about the USB. Makes me wonder about the comments above from Dexter. Wonder whether he is referring to a CPP Class -- or the Class of Hardware -- USB1 vs USB2 vs USB3 -- or a "better class of" interface chip regardless of USB class.My ASUS M4A motherboard only has USB2.0 Interfaces -- I could add a USB3 card if that would help in my case. They are cheap. <$30 I think.

Re the RS232: I designed a lot of RS232 hardware in my early career -- good thing I never saw a spec about 20KBbps -- although I would have likely ignored it and tried things anyway. I am told that I am disrespectful of authority though -- and it's probably true.

Perhaps the problem is in the actual transfer code -- so on the LM3S811 I will try to see if I can squeeze out some more speed. If I can then I will feel safer about moving my development to LM4F series.

At least I know someone else was successful and that is all a good designer needs to know -- right? :-)

Maye the OP will chime in with more information.

I was referring to the USB device class in terms of drivers and functionality not USB 2.0 versus USB 3.0.

Current Stellaris devices are USB 'full' speed only.  This is the 12.0Mbps physical transfer speed over the USB bus. Regardless of the hosts speed capabilities this is the speed of transfers to and from the Stellaris. However the virtual serial port device class (logical class) is not the most efficient way to utilize that bandwidth.  We have found that the "bulk" device class can transfer more data more efficiently.  This becomes much more a study in USB rather than Stellaris.

Dexter

Dexter:

Thank you. (For depressing me.)

I have enough to learn -- maybe I will get one of the I2C devices I pointed out earlier. Any chance we will see an LM4F232 with Ethernet any day soon? I have all the UDP stuff working so...

Anyway -- helpful to know what approach might work best.

Anyway -- I will write (I2C) libraries for the BMA180 (accelerometer) and the BMP085 (Barometric Pressure) while you guys sort out the Ethernet... Any chance it could be ready in a week or so? :-/

Dave Robinson said:

Any chance we will see an LM4F232 with Ethernet any day soon?

Do not see HOW you could have missed with the absolute clarity/detail provided by the neat Ad Dexter appended.  What further detail could you possibly require?   And you claim that you have, "trouble with authority!"  (BTW - where is Andy?)

cb1_mobile:

Just needless complaining on your part... Have another coffee and relax! The detail was sufficient that I am approaching completion of my new Interstellar Warp Drive Controller with said board using specs kindly (though inadvertently) provided by TI. Will send message from Alpha Centauri upon imminent completion of project. ;-)

Will order two -- the second is to run the coffee machine in the ship lounge.

Cheers!

I am using the QSlogger application and changed the logging rates to meet my requirements . I am able achieve upto 2KHZ rate properly.

My goal is monitor the one of the Channel @5KHZ rate log into the USB or SD Card.

Why are you polling the USB that fast?  What led you to try increasing this polling rate?  This seems like it may cause more complications than solutions.  This could create more unneeded traffic on the USB bus.

You have had success at 2Khz.  What failed at 5khz?  

First find out if the problem was with data sampling or data storage?  

If the problem was data sampling then a different trigger mechanism or the use of the uDMA may be needed.

If the problem was data storage (more likely) then you will need to investigate what is the data storage rate of the device you want to use.  Store a sample data-set in flash or SRAM and store that to the memory stick.  Measure how long it takes to move a known size of data to the storage device.  Then investigate methods to increase this throughput such as uDMA.

Dexter