Dear Kelly, Your suggestion seems very helpful to me. Actually, I am having difficulties in unstable offset between PC clock and BT clock with jitters. I am planning to mitigate jitters by approaching it in statistical manner. However, your suggestion seems to solve the problem from more fundamental point.
Regards, Jeon. On Mon, Oct 17, 2016 at 11:16 PM, devin kelly <dwwke...@gmail.com> wrote: > 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
