0

I have a Raspberry Pi 2 Model B and i want send data from my raspberry to my laptop and view them there in realtime. I have a bus with a 9 bit protocol with 4800 baud and make 14400 sampels per second with my software uart. Now i switch the endless datasteam with my uart to a hexbyte and a timestemp and so on, that datastream want i stream from the raspberry to my laptop.

I read, that stream data from raspberry to a windows pc over usb is verry difficult. So i think it´s easier to make a TCP server on the raspberry and take the data from them with the laptop over the ethernet.

Because i´m using the Raspberry only 2 weeks i think i ask here if someone has a better option?

Thanks for answers @ all

Best regards sniffi

3
  • Your question lacks vital information to be answerable. Real time is not necessarly "ultra-fast" and "high bandwidth". You need to define your acceptable latency and necessary bandwidth (among other constraints and requirements).
    – Ghanima
    May 17, 2016 at 8:21
  • Sry i have fix it sofar i can. I hope it´s ok now.
    – sniffi
    May 17, 2016 at 9:16
  • Please have also a look here as it has been pointed out that your question is still quite broad and might therefore attract answers that might not serve your need.
    – Ghanima
    May 18, 2016 at 11:12

3 Answers 3

0

This is a tough question and without knowing a lot more about your setup my answer is going to be fairly general. As noted, realtime has a very specific definition in computing and you aren't going to be able to achieve that. You can easily achieve "realtime" though. The difference? Probably about 10~30ms in your use case.

You don't mention how the datastream is collected in the Pi - either in memory or as a file or whatever - but the only question that matters is:

Can you get a handle on this stream in your favourite programming language on the Pi?

If you can, you've won half the battle. All you need to do now is get it into a stream. I say 'all', this is still a big step.

The classic transport for this type of data (continuous stream) would be UDP but I'll probably advise TCP for a couple of reasons.

UDP: continuous stream of data, fast, lightweight. You'll have to worry about error detection and out of order packets yourself (though maybe less of an issue if each of your 'packets' has a timestamp).

TCP: more packet based than UDP, higher overhead (data about data) to data ratio. Built-in error detection and resend request, built-in packet ordering when the data arrives at the application layer.

My advice - if absolute to-the-bone performance is not needed - would be to grab a WebSockets library for your favourite programming language on the Pi and write a simple server that reads your stream and fires it to a client on your Windows machine. You can buffer the stream into packets as you wish on the server - packet frequency vs packet size - and fire them at the clients as you need to.

You can then write a simple HTML and JavaScript client on the Windows machine to read from the server on the Pi. Once you have the packets being received by the client you can either dump them to screen or write a more complicated analytics application.

Please note that JavaScript is just a simple way of writing a WebSockets client; you can also grab a WebSockets library for your favourite language on your Windows machine and have at it.

1
  • Thanks for help i will try it on this way. And sry again for my bad question, all what i do at the moment is advance investigation. I haven´t implementet something at the moment but i want start now. I think i have all what i need, my favourite programming language on the pi is C and on my Laptop is it C#. That all is for my practice semester and yes i must write a analytic application for a special databus. my problem is i have never do what with embeded also i try many the first time.
    – sniffi
    May 19, 2016 at 5:38
3

You can do some experiments without writing any code just using the command-line in your Terminal. I suggest you use netcat, also known as nc.

So, on your laptop, you could run the following to act as a server and listen on port 2000:

nc -l 2000 > received.dat

And on the Raspberry Pi, use the following to send 1,000 blocks of zeroes each 14,400 bytes long to your laptop (assuming your laptop has IP address 192.168.0.8):

dd if=/dev/zero bs=14400 count=1000 | nc 192.168.0.8 2000

Then you will see the data in the file received.dat on your PC.

Once you have that working, you can experiment with using UDP instead of the default TCP by adding -u to the command-line.

Then you can add -k o the options on the server-side, and it will continue listening after the connection is closed - this will be useful for continuous streaming and stop/starts.

Link to netcat Cheatsheet

0

Use ftp, thats in my opinion your best option, do thhe following: install filezilla server on your windows pc when thats done head to your pi and type: ftp your.ip.here. then type your username and password you made for the server and done. use put filename to send something to windows, and get filename to get something from windows

6
  • ftp would have been my last guess to be used for streaming.
    – Ghanima
    May 18, 2016 at 9:29
  • he doesnt want to stream... take the data from them with the laptop over the ethernet.
    – patrick
    May 18, 2016 at 10:07
  • I beg to object: Now i have a endless datasteam from zeros and ones, that datastream want i send from the raspberry to my laptop.
    – Ghanima
    May 18, 2016 at 10:20
  • a datastream can be anything really, it can be a file being transfere, a video, a picture, ssh is too zero's and one's its just Data, data can be anything from something tiny to something massive
    – patrick
    May 18, 2016 at 10:38
  • Sry for my bad Question i have fix it at the question, i want stream the datastream to the laptop.
    – sniffi
    May 18, 2016 at 12:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.