Jeon, If you're just trying to get the results from 'hcitool clock', I'd look at the source code for hcitool and just copy that code. You'll probably have to add some extra #includes and link to a few extra libraries. This way you won't get any extra latency that's added when you create new processes.
You can start looking here: http://git.kernel.org/cgit/bluetooth/bluez.git/tree/tools/hcitool.c Hope this helps, Devin On Sat, Oct 15, 2016 at 9:26 AM, Jeon <sjeon87+gnura...@gmail.com> wrote: > Thank you, Marcus. > > I've implemented code to get MAC address(hcitool dev) in a black class > constructor. > > On the other hand, implementing code to get device's clock (hcitool clock) > in start() did not work well, maybe due to my little knowledge. Anyway, > since I have to get clocks repeatedly, I think it's good to implement in > [general_]work(). > > Ah, my aim is to build a system that takes Bluetooth device's MAC address > and clock, and calculates frequency hopping sequence. And finally I want to > make GNU Radio react to the calculated hop sequence. (Not only sticking on > simulation). > > I'll post again if further progress. > > Regards, > Jeon. > > On Wed, Oct 12, 2016 at 9:36 PM, Marcus Müller <marcus.muel...@ettus.com> > wrote: > >> Hi Jeon, >> >> Your use case is not what you'd use controlport for; I think you've got >> it right: use modtool to create a sync block, but set its number of in- and >> outputs to zero; override the start() method to spawn a new thread that >> contains a function which has a loop that executes the external command, >> publishes a message, and repeat. >> >> Anyway, your requirement: >> >> > One condition is, I need to retrieve contents from "hcitool clock" as >> fast as the system (GNU Radio) can. >> >> conflicts with the idea of message passing – message passing doesn't >> allow backpressure, so you'll just flood the message receiver's message >> input, and that would be useless. >> >> What do you want to do with that data? If it's something that makes sense >> to be understood as stream of samples, go for the classical GNU Radio >> source block and write the data to the output stream. >> >> >> Best regards, >> >> Marcus >> On 12.10.2016 14:16, Jeon wrote: >> >> Just get to the point. >> >> I have a Bluetooth dongle connected to my PC. I can read a MAC address >> and internal clock value by typing `hcitool dev` and `hcitool clock` in >> command line. You can see demo in link below: >> >> http://i.imgur.com/hbQcBQq.png >> >> What I want is to make GNU Radio get those values/contents. >> >> Currently, I've planned to make a source block expressed in pseudocode: >> >> work(args) { >> file_pointer = popen("hcitool dev"); // or "hcitool clock" >> buf = read(fp); >> val = some_char_array_manipulation(buf); >> publish_message(val); >> pclose(file_pointer); >> } >> >> Recently, I found that ControlPort can bridge GNU Radio and other >> programs. Well, however, I am new to ControlPort (just used for >> PerfMonitor) and seems more complicated than the pseudocode above. >> >> Which would you recommend? One condition is, I need to retrieve contents >> from "hcitool clock" as fast as the system (GNU Radio) can. >> >> Regards, >> Jeon. >> >> >> _______________________________________________ >> Discuss-gnuradio mailing >> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> >> >> _______________________________________________ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
