Hi Jalil, please always make sure to reply to the mailing list rather than to individual persons :) > The application is not GUI based, it just utilizes the Signal/Slot > architecture of Qt framework. That can be quite handy, but still requires Qt to be on the target platform. Maybe Philip can comment on the support of Qt in the different images we have for the E310.
> I intend to make a QThread object, to run the GR scheduler in separate > thread. The GR scheduler itself is very multithreaded :) every block runs in its own thread. Your approach of starting the flowgraph in its own QThread seems sound. > For now, I just need to send/receive some one-byte commands, so I > think the message sink/source would be good for this stage. Yes, since you are in the same process, that should work. > What type of modulation/demodulation is recommended for this environment? That's a question hard to answer without knowing a lot more. Generally, go for something simple, robust, for a start. However, I don't know your drone system. Maybe they move very fast relative to each other, so you need to build receivers that are very resistant to Doppler; maybe you don't. Doppler depends (aside from relative speed) on carrier frequency, so what works on 75MHz doesn't have to work on 5GHz. What carrier frequency you use depends on what antennas you want to use, which depends on the mechanical/aeronautical aspects of your design. Maybe you have something with large metal rotors; that can look very disturbing in the spectrum (doppler due to reflection on fast moving blades + choppy transmissions if the blades are somewhere in the signal path). Maybe your drones are a few meters away from each other, allowing you to use the 2.4/5GHz ISM band, maybe they are miles apart, calling for lower frequencies due to lower attenuation. I'd still try with one of the PSK modulators in GNU Radio, and maybe a simple preamble correlation after that to allow commands to be detected. But what you're asking is basically one of the central questions of digital communications, and it's not universally answered. Best regards, Marcus On 06/28/2015 05:09 PM, Jalil Modares wrote: > Dear Marcus: > > Thank you so much for your suggestions. > > I'm an Electrical Engineering Ph.D. student, at State University of > New York, working on a project, which demands real time data streaming > between different drones. > The application is not GUI based, it just utilizes the Signal/Slot > architecture of Qt framework. > I intend to make a QThread object, to run the GR scheduler in separate > thread. > For now, I just need to send/receive some one-byte commands, so I > think the message sink/source would be good for this stage. > > Is that design fine? > What type of modulation/demodulation is recommended for this environment? > > Thanks again for your time. > > Regards, > Jalil > > > On Sun, Jun 28, 2015 at 5:19 AM, Marcus Müller > <[email protected] <mailto:[email protected]>> wrote: > > Hi Jalil, > > unless you install Qt on it and attach a screen to it, it will be > hard to use a Qt application on your E310. > Basically, the E310 is just a linux computer on an embedded > device, which means you can do the same as on your fully fledged > Linux PC -- the question is if you should: The E310 is an embedded > device with a energy-efficient ARM CPU, that is in no way optimal > for graphical front ends, so visualizing some data on the E310 > might be more stressful to the CPU of the E310 than it is for the > CPU of your PC; that together with the fact that the USRP's CPU is > much slower might make your application unusable; it really depends. > > You say >> I already made the GRC diagram, but grc generates python codes. > So, yes, that is how GRC works. > There's multiple options on how you can integrate the resulting > flow graph into your application: > * You could re-implement that flow graph in C++ instead of python. > The functions are all the same (top_block.connect etc); then you > could use the message_sink / _source to get information in and out > of GNU Radio via queues. > * You could use different sinks and sources to get your data in > and out of your flow graph: For example, you can use the file sink > and source with a Unix FIFO instead of a normal file, and > write/read that FIFO from within your application. You can use > ZeroMQ sinks and sources with "ipc://" URLs, so your Qt > Application and your GNU Radio flowgraph would run in different > processes, but still be able to communicate. > * You could write a GNU Radio C++ block that wraps your > application; that would be about as elegant as the > message_sink/_source approach, but I'd ask you to realize that > it's very important to make the Qt Application work in the > python/GRC-provided QtApplication instance, and pass the data from > GNU Radio to your application in a multithreading-safe manner (ie. > the block has to be able to run asynchronously to your GUI threads) > * You could run your Qt Application on a PC that already has a > screen, and use network sinks and sources (TCP, UDP, or, I > consider this to be superior, the ZeroMQ blocks), to transport the > things you want to get into your application over network. Notice > that it will be very hard to get high rates out of the USRP, but > visualizing data at these high rates will probably be even harder > to do on the E310. > > Best regards, > Marcus > > Best regards, > Marcus > > > On 06/28/2015 01:55 AM, Jalil Modares wrote: >> Dear All: >> >> I need to have a RF link between two E310. >> My application is written is C++/ using Qt framework. >> I already made the GRC diagram, but grc generates python codes. >> Is there any source to help me integrate that code to my application. >> >> Thanks, >> jmod >> >> >> _______________________________________________ >> Discuss-gnuradio mailing list >> [email protected] <mailto:[email protected]> >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > _______________________________________________ > Discuss-gnuradio mailing list > [email protected] <mailto:[email protected]> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > >
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
