Re: [Discuss-gnuradio] Getting values from external program.

2016-10-17 Thread Jeon 
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  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  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 
>> 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

Re: [Discuss-gnuradio] Getting values from external program.

2016-10-17 Thread Jeon 
Not a problem, just an idea came into my head.

Since MAC address (48 bits) can be contained in one long long-type
variable, and BT clock (28 bits) can be contained in one integer-type
variable in C++, I can just send those values along a stream. If an offset
is considered, a smaller data type can be used.

Regards,
Jeon.

On Wed, Oct 12, 2016 at 9:36 PM, Marcus Müller 
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

Re: [Discuss-gnuradio] Getting values from external program.

2016-10-17 Thread devin kelly 
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  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 
> 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

Re: [Discuss-gnuradio] Getting values from external program.

2016-10-15 Thread Jeon 
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 
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

Re: [Discuss-gnuradio] Getting values from external program.

2016-10-12 Thread Marcus Müller 
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 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