eti-cmdline: PIPE support for changing the frequency

[lars18th]

Hi @JvanKatwijk ,

In order to support a simple method for use "eti-cmdline-*" in conjunction with DABlin and enable the option for changing the frequency I suggest this "simple" change:

• Add support for reading from the PIPE stdin file for commands. These commands can mimic (for convenience) the format used in the RTL_TCP tool. So, at time the idea is to only support the cmd "0x01" (set freq : https://github.com/osmocom/rtl-sdr/blob/master/src/rtl_tcp.c#L307). As this protocol is mainly async, for changing a frequency the pseudo-code algorithm in the server side is quite simple:

 while (data in the STDIN) {
    in=readline(STDIN);  // Only read 5 bytes!
    cmd=in[0];
    param=ntohl(in[1:4]);
    if (cmd=0x01)
       change_freq(param);
 }

You think it's good idea to support this? In any case, this doesn't change the current behaviour. So, current tools don't see any change, and it doesn't disturbs.

Note: In the client side (for instance, in DABlin) the code will be even simpler!

[JvanKatwijk]

It would require an additional thread to listen

2018-03-05 17:06 GMT+01:00 lars18th notifications@github.com:

Hi @JvanKatwijk https://github.com/jvankatwijk ,

In order to support a simple method for use "eti-cmdline-" in conjunction with DABlin and enable the option for changing the frequency* I suggest this "simple" change:

• Add support for reading from the PIPE stdin file for commands. These commands can mimic (for convenience) the format used in the RTLTCP tool. So, at time the idea is to only support the cmd "0x01" (set freq : https://github.com/osmocom/rtl-sdr/blob/master/src/rtl tcp.c#L307). As this protocol is mainly async, for changing a frequency the pseudo-code algorithm in the server side is quite simple:

  while (data in the STDIN) { in=readline(STDIN); // Only read 5 bytes! cmd=in[0]; param=ntohl(in[1:4]); if (cmd=0x01) change_freq(param); }

You think it's good idea to support this? In any case, this doesn't change the current behaviour. So, current tools don't see any change, and it doesn't disturbs.

Note: In the client side (for instance, in DABlin) the code will be even simpler!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/JvanKatwijk/eti-stuff/issues/34, or mute the thread https://github.com/notifications/unsubscribe-auth/AITzwOnyyvjOn3PR_h-Qaq-ECpLazabwks5tbWJdgaJpZM4Scivv .

-- Jan van Katwijk

+31 (0)15 3698980 +31 (0) 628260355

[JvanKatwijk]

... but one of the advantages of open source is that you can see the sources and add or suggest the required modifications. To me it is a non-issue

2018-03-05 17:46 GMT+01:00 jan van katwijk j.vankatwijk@gmail.com:

It would require an additional thread to listen

2018-03-05 17:06 GMT+01:00 lars18th notifications@github.com:

Hi @JvanKatwijk https://github.com/jvankatwijk ,

In order to support a simple method for use "eti-cmdline-" in conjunction with DABlin and enable the option for changing the frequency* I suggest this "simple" change:

• Add support for reading from the PIPE stdin file for commands. These commands can mimic (for convenience) the format used in the RTL_TCP tool. So, at time the idea is to only support the cmd "0x01" (set freq : https://github.com/osmocom/rtl-sdr/blob/master/src/rtl_tcp. c#L307). As this protocol is mainly async, for changing a frequency the pseudo-code algorithm in the server side is quite simple:

  while (data in the STDIN) { in=readline(STDIN); // Only read 5 bytes! cmd=in[0]; param=ntohl(in[1:4]); if (cmd=0x01) change_freq(param); }

You think it's good idea to support this? In any case, this doesn't change the current behaviour. So, current tools don't see any change, and it doesn't disturbs.

Note: In the client side (for instance, in DABlin) the code will be even simpler!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/JvanKatwijk/eti-stuff/issues/34, or mute the thread https://github.com/notifications/unsubscribe-auth/AITzwOnyyvjOn3PR_h-Qaq-ECpLazabwks5tbWJdgaJpZM4Scivv .

-- Jan van Katwijk

+31 (0)15 3698980 <+31%2015%20369%208980> +31 (0) 628260355 <+31%206%2028260355>

-- Jan van Katwijk

+31 (0)15 3698980 +31 (0) 628260355

[lars18th]

... but one of the advantages of open source is that you can see the sources and add or suggest the required modifications.

Well. The Issues section is the regular point in GitHub to discuss errors/ideas/bugs/etc. For this reason I put here. If I need to use another forum, please let me know. In any case, I ask to know your opinion before starting a fork to collaborate.

It would require an additional thread to listen

This is another reason for asking. I'm not sure about where to put the code. I have the idea very clear. But when using threads it's required to have a clear image of the entine structure. And regarding the "eti-cmdline" I don't have a clear image.

First of all: You think this idea has sense?

[JvanKatwijk]

no

2018-03-05 18:13 GMT+01:00 lars18th notifications@github.com:

... but one of the advantages of open source is that you can see the sources and add or suggest the required modifications.

Well. The Issues section is the regular point in GitHub to discuss errors/ideas/bugs/etc. For this reason I put here. If I need to use another forum, please let me know. In any case, I ask to know your opinion before starting a fork to collaborate.

It would require an additional thread to listen

This is another reason for asking. I'm not sure about where to put the code. I have the idea very clear. But when using threads it's required to have a clear image of the entine structure. And regarding the "eti-cmdline" I don't have a clear image.

First of all: You think this idea has sense?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/JvanKatwijk/eti-stuff/issues/34#issuecomment-370491904, or mute the thread https://github.com/notifications/unsubscribe-auth/AITzwAdzFf1l1cSKt_jmS4LNEVlGuJH_ks5tbXIAgaJpZM4Scivv .

-- Jan van Katwijk

+31 (0)15 3698980 +31 (0) 628260355

[basicmaster]

Note: In the client side (for instance, in DABlin) the code will be even simpler!

No, it won't be simpler: DABlin currently uses popen to invoke the respective DAB live source. This POSIX command however is limited and only allows to either read from stdin or to write to stdout. As reading from stdin is required for the actual ETI data, a back channel at the same time is not possible using popen.