Hi all, I am currently working on a project in which the Due is picking up data at a rate of 4 Mbps (this part is working properly). The current setup of the system is that it takes in 8 bits and then outputs the byte through SerialUSB.write() to a Windows laptop, however the speeds I am currently getting are much too slow and I am losing data coming into the D I/O pin in the time it takes for the code to output the values via USB.
What is the fastest way to transfer data from the Due to a computer with at least a 8 Mbps data rate? (ethernet, USB, bluetooth, wifi, etc)
Also is there any more efficient way to output the data from the system. I was playing around with the idea of updating 8 pins to hold the value of the byte and then use some form of parallel communication, but I don't know what additional hardware I would need.
Serial comm to/from PC/arduino is very slow for your purpose, at least the monitor implementation and, I guess, even the direct (not monitor) speed. I would discard this.
Should it be "real time"? (I mean: is the computer to use the data rigth as it comes?)
The system does not need to be real time, but I have a limitation of a max of 1-2 seconds delay from the time the data is received by the Due until it must be displayed on the screen. (This amount of time would overflow the onboard storage of the Due if we were to let it store values continuously and then push them all at once to the computer).
On the computer side, the data must be stored (most likely in a csv or txt file) and plotted on a graph. I plan on using C# for the storage and processing side of things.
It seems that the limitation of the serial application is that the computer does not look for incoming data at a high enough rate (I remember hearing 1 ms delay between successive samples). If this is the case, is there some way to set up a Due to communicate with a PC using an isochronous system instead of the default, and if so would that work?
Would I be able to hack together an interface from I/O ports on the board to a 3.5 mm plug and use the computer's sound card to receive and process the data?
Would I be able to hack together an interface from I/O ports on the board to a 3.5 mm plug and use the computer's sound card to receive and process the data?
You're asking us about your technical skills? I'd have to say no.
I'm asking if the computer's sound card would be able to sample data being input to the audio port at a fast enough rate to not lose data.
Have you considered testing that? Plug a microphone in, and sing to your computer. Play back what you recorded. Does that sound reasonable? Aside from that fact that you can't sing? 8)
The REAL question is whether the Arduino can output data in audio format fast enough. And, that I can't answer. My gut feeling is that converting the data that it has, whatever it is, to audio data and outputting the audio data is not going to be possible or fast.
I am perfectly capable of splicing cables together, I just don't know if it will work once I plug it in.
I wouldn't plug "it" into the computer. Might not get "it" back out. On the other hand, you might have meant something else by "it".
This seems to be the same issue as in your other Thread here. I have already contributed to the other Thread. Why are you wasting people's time by double posting.
Please ask the Moderator to merge the two Threads.
Thanks Robin, I started this thread separately because the other one was focused solely on the SerialUSB functions whereas this one is concerned with alternatives to that method. (However, if you feel that the two need to be merged, I will take care of that)
I am now looking into writing to 8 digital pins on the arduino to display the byte and then route that to an EPP parallel port which should be able to handle the speeds I need to get (Max of 2 MB/s according to IEEE 1284).
I can update the digital I/O pins in a timely manner, but I am unsure about how to use this interface to communicate with a computer.
bobloblaw651:
I am now looking into writing to 8 digital pins on the arduino to display the byte and then route that to an EPP parallel port which should be able to handle the speeds I need to get (Max of 2 MB/s according to IEEE 1284).
That sounds like you did not read the last paragraph in Reply #12 in the other Thread.
And that is why all the stuff should be in one Thread.