[WIP] eti-cmdline: FIFO controller file

[lars18th]

Hi,

This is a Work-In-Progress. But I like to know your opinion about this idea:

• After a lot of trials with the objective of a "remote" control for the eti-cmdline tool (mainly for changing the frequency) I found a "simple" solution. The solution is to add support for a FIFO contoller file. This file is passed as a parameter to the tool and when it exists you can send control commands. The protocol will be identical to the well known RTL_TCP (5 bytes for each packet, first byte the 'cmd' and the last four bytes an int32 as 'param'). So, when your send to this FIFO the command for changing the frequency, the tool will change the value internally. This file can be a FIFO file or a '3' PIPE between two programs (note that even file descriptors 0,1,2 exists for STDOUT, STDIN & STDERR I/O streams, you can use upper values like '3' if you like).

Here some comments about this solution:

• If you don't use this file nothing changes, so it will be transparent and not disturbing.
• Using this solution, and when eti-backend and DABlin (or others) will have support to this, then you can run something like eti-cmdline -c /tmp/eti-cmd.sock | dablin -x /tmp/eti-cmd.sock. And you have the option for changing the frequency.
• As the protocol is unidirectional, the client process needs only to write 5 bytes in the control file for sending a command.
• In the eti-cmdline is only required to check regulary if new data comes to the control file. You can read it from time to time, so you don't disturb threads.
• And finally the eti-cmdline requires that all driver handlers implement the corresponding functions for changing the frequency at any time.

I hope that you will agree with this approach this time. Your comments are welcome. The idea is to put this into practice on my own.

And regarding the question Why you need to change the frequency instead of restart the tool? the answer is: _Because restarting will consume a lot of time. Specifically using the RTLTCP driver this implies more than 1 second only for reconnecting to the server. Plus the time to restart the eti-cmdline process. So sending only a message to change the frequency will be much more efficient.

Regards.

[JvanKatwijk]

For control you need an additional thread in the main program, just to listen to commands. Given that you create a thread, the most simple - and in my view elegant - solution is then to create a listener that listens to an ip port. In dab-cmdline, i think example 6, this was demonstrated. Op 7 mrt. 2018 09:40 schreef "lars18th" notifications@github.com het volgende:

Hi,

This is a Work-In-Progress. But I like to know your opinion about this idea:

• After a lot of trials with the objective of a "remote" control for the eti-cmdline tool (mainly for changing the frequency) I found a "simple" solution. The solution is to add support for a FIFO contoller file. This file is passed as a parameter to the tool and when it exists you can send control commands. The protocol will be identical to the well known RTL_TCP (5 bytes for each packet, first byte the 'cmd' and the last four bytes an int32 as 'param'). So, when your send to this FIFO the command for changing the frequency, the tool will change the value internally. This file can be a FIFO file or a '3' PIPE between two programs (note that even file descriptors 0,1,2 exists for STDOUT, STDIN & STDERR I/O streams, you can use upper values like '3' if you like).

Here some comments about this solution:

• If you don't use this file nothing changes, so it will be transparent and not disturbing.
• Using this solution, and when eti-backend and DABlin (or others) will have support to this, then you can run something like eti-cmdline -c /tmp/eti-cmd.sock | dablin -x /tmp/eti-cmd.sock. And you have the option for changing the frequency.
• As the protocol is unidirectional, the client process needs only to write 5 bytes in the control file for sending a command.
• In the eti-cmdline is only required to check regulary if new data comes to the control file. You can read it from time to time, so you don't disturb threads.
• And finally the eti-cmdline requires that all driver handlers implement the corresponding functions for changing the frequency at any time.

I hope that you will agree with this approach this time. Your comments are welcome. The idea is to put this into practice on my own.

And regarding the question Why you need to change the frequency instead of restart the tool? the answer is: Because restarting will consume a lot of time. Specifically using the RTL_TCP driver this implies more than 1 second only for reconnecting to the server. Plus the time to restart the eti-cmdline process. So sending only a message to change the frequency will be much more efficient.

Regards.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/JvanKatwijk/eti-stuff/issues/37, or mute the thread https://github.com/notifications/unsubscribe-auth/AITzwI4TdZvBnzjjK1Xne4L9IKRFyDw3ks5tb50LgaJpZM4SgDis .

[lars18th]

Hi @JvanKatwijk ,

Thank you for your comment! I'm glad to hear it. :smile:

Regarding your suggestions:

1. The use of a listening socket, in my personal opinion, is less elegant and more complex to implement. For sure, it will be more flexible. But using an unidirectional protocol it's in fact irrelevant. If you need to use the network, then you can use tools like NetCat or SoCat to achive it. In any case I'll review the example 6. Perhaps I'll modify my opinion.

2. Instead of adding a new thread, just to receive only control commands, my idea is to use the main thread. The checking of new commands can be done only time to time. Perhaps each 100ms (10 times a second). So, this doesn't disturbs any other process. What you think?

3. My concern now is about the "re-tune" when changing the frequency. You think that the current code will work as expected when I call to deviceHandler::setVFOFrequency() from the main thread?

Regards.

[JvanKatwijk]

It is obviously a matter of taste. Wrt 2 i wouldnot recommend adding a timer interrupt for polling commands. Wrt 3, no it is not sufficient to just set the vfo, the whole processing chain has to be rest and restarted. First have a look at the example in dab-cmdline Op 7 mrt. 2018 10:51 schreef "lars18th" notifications@github.com het volgende:

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

Thank you for your comment! I'm glad to hear it. 😄

Regarding your suggestions:

1.

The use of a listening socket, in my personal opinion, is less elegant and more complex to implement. For sure, it will be more flexible. But using an unidirectional protocol it's in fact irrelevant. If you need to use the network, then you can use tools like NetCat or SoCat to achive it. In any case I'll review the example 6. Perhaps I'll modify my opinion. 2.

Instead of adding a new thread, just to receive only control commands, my idea is to use the main thread. The checking of new commands can be done only time to time. Perhaps each 100ms (10 times a second). So, this doesn't disturbs any other process. What you think? 3.

My concern now is about the "re-tune" when changing the frequency. You think that the current code will work as expected when I call to deviceHandler::setVFOFrequency() from the main thread?

Regards.

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

[JvanKatwijk]

The example 6 was developed some time ago for someone who intended to create a remote handling facility for dab-cmdline. The tcp-handler can be used almost immediately for eti-cmdline. Obviously the command to select a service should be removed. There is a command to set the gain of the device as well.

Changing the channel is a major operation for the backend and brings disruption of the output (obviiously)

In my opinion it is the most flexible solution and can be integrated with some "ifdef" constructs in the current eti-cmdline implementation easily. However, it is your choice

2018-03-07 11:02 GMT+01:00 jan van katwijk j.vankatwijk@gmail.com:

It is obviously a matter of taste. Wrt 2 i wouldnot recommend adding a timer interrupt for polling commands. Wrt 3, no it is not sufficient to just set the vfo, the whole processing chain has to be rest and restarted. First have a look at the example in dab-cmdline Op 7 mrt. 2018 10:51 schreef "lars18th" notifications@github.com het volgende:

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

Thank you for your comment! I'm glad to hear it. 😄

Regarding your suggestions:

1.

The use of a listening socket, in my personal opinion, is less elegant and more complex to implement. For sure, it will be more flexible. But using an unidirectional protocol it's in fact irrelevant. If you need to use the network, then you can use tools like NetCat or SoCat to achive it. In any case I'll review the example 6. Perhaps I'll modify my opinion. 2.

Instead of adding a new thread, just to receive only control commands, my idea is to use the main thread. The checking of new commands can be done only time to time. Perhaps each 100ms (10 times a second). So, this doesn't disturbs any other process. What you think? 3.

My concern now is about the "re-tune" when changing the frequency. You think that the current code will work as expected when I call to deviceHandler::setVFOFrequency() from the main thread?

Regards.

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

-- Jan van Katwijk

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

[lars18th]

Hi @JvanKatwijk ,

I really appreciate your feedback, thank you!

First have a look at the example in dab-cmdline

I'll do! :smile:

i wouldnot recommend adding a timer interrupt for polling commands

This isn't my idea. The current mainloop is doing sleeps... https://github.com/JvanKatwijk/eti-stuff/blob/master/eti-cmdline/main.cpp#L409 My idea is put here the code to check if new incoming command are in the control file waiting to process it. I think it's not a bad idea, right?

no it is not sufficient to just set the vfo, the whole processing chain has to be rest and restarted.

:cry: My objective isn't "restart" the driver, only change the frequency. This is required for a fast frequency change. For sure, I feel I need to call to driverHandler::restartReader(), and before stop the processing thread. However, I susposed that will be sufficient with this pseudo-code:

::changeFrequency() {
  driverHandler::pause();
  driverHandler::setVFOFrequency();
  driverHandler::restartReader();
}

You think this makes sense? Or am I completely wrong and none of this is possible?

Regards.

[lars18th]

Hi @JvanKatwijk ,

The example 6 was developed some time ago for someone who intended to create a remote handling facility for dab-cmdline. The tcp-handler can be used almost immediately for eti-cmdline. Obviously the command to select a service should be removed. There is a command to set the gain of the device as well.

Ok. I'm starting to review the example 6: https://github.com/JvanKatwijk/dab-cmdline/tree/master/example-6

Changing the channel is a major operation for the backend and brings disruption of the output (obviiously)

But, as the output is ETI-NI, my intent is to do the change without interruption (perhaps some NULL frames in the middle). The player will handle after the change (that's the one has requested the change!).

In my opinion it is the most flexible solution and can be integrated with some "ifdef" constructs in the current eti-cmdline implementation easily. However, it is your choice

I'll try to be clear and safe.

Thank you!

[JvanKatwijk]

If you change the channel, then all "knowledge" built up from the previous one is obsolete. So you have to reset and restart everything that has some form of "memory" on the data that is passing. So, you end up with something like ofdmHandling -> stop fibHandling/ficHandling reset change the frequency restart the ofdmHandling

which amounts to restarting everything in the processing chain

Just have a look at example 6, The sequence of commands to change the channel is there (obviously regardless of where the command is coming from)

          theRadio  -> stop ();
          theDevice -> stopReader ();
          my_radioData -> theChannel = std::string ((char *)(&buffer

[1])); { int frequency = theBandHandler -> Frequency (my_radioData -> theBand, my_radioData -> theChannel); theDevice -> setVFOFrequency (frequency); } theRadio -> startProcessing (); theDevice -> restartReader ();

Since the eti-cmdline software was built with the idea that a frequency was fixed when starting, you should at least have a look what possibilities there are for the main controller (Radio in dab-cmdline) to stop and restart

2018-03-07 11:17 GMT+01:00 lars18th notifications@github.com:

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

I really appreciate your feedback, thank you!

First have a look at the example in dab-cmdline

I'll do! 😄

i wouldnot recommend adding a timer interrupt for polling commands

This isn't my idea. The current mainloop is doing sleeps... https://github.com/JvanKatwijk/eti-stuff/blob/master/eti-cmdline/main.cpp# L409 My idea is put here the code to check if new incoming command are in the control file waiting to process it. I think it's not a bad idea, right?

no it is not sufficient to just set the vfo, the whole processing chain has to be rest and restarted.

😢 My objective isn't "restart" the driver, only change the frequency. This is required for a fast frequency change. For sure, I feel I need to call to driverHandler::restartReader(), and before stop the processing thread. However, I susposed that will be sufficient with this pseudo-code:

::changeFrequency() { driverHandler::pause(); driverHandler::setVFOFrequency(); driverHandler::restartReader(); }

You think this makes sense? Or am I completely wrong and none of this is possible?

Regards.

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

-- Jan van Katwijk

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

[lars18th]

Hi @JvanKatwijk ,

Since the eti-cmdline software was built with the idea that a frequency was fixed when starting, you should at least have a look what possibilities there are for the main controller (Radio in dab-cmdline) to stop and restart

Thank you for all this info. I think now that it can be more complex than initially I feel.

In any case, what I really like to overcome is the reinitialization of the driver. For example, using the RTL-TCP driver I don't like to close the TCP socket, just send the ChangeFrequency command. However, it's clear than some parts of the bitstream will be lost.

Regards.

[JvanKatwijk]

The design is push-based. The clock is the device clock. If the device does not provide samples then no output will be genersted. Even further: if there is no timesync, then no data will be send to furthrr processing parts. If you want a continuous output stream, then you have to redesign such that the rti generating part is the driver. Complete rewrite. Op 7 mrt. 2018 11:54 schreef "lars18th" notifications@github.com het volgende:

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

Since the eti-cmdline software was built with the idea that a frequency was fixed when starting, you should at least have a look what possibilities there are for the main controller (Radio in dab-cmdline) to stop and restart

Thank you for all this info. I think now that it can be more complex than initially I feel.

In any case, what I really like to overcome is the reinitialization of the driver. For example, using the RTL-TCP driver I don't like to close the TCP socket, just send the ChangeFrequency command. However, it's clear than some parts of the bitstream will be lost.

Regards.

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

[lars18th]

The design is push-based. The clock is the device clock. If the device does not provide samples then no output will be genersted. Even further: if there is no timesync, then no data will be send to furthrr processing parts. If you want a continuous output stream, then you have to redesign such that the rti generating part is the driver. Complete rewrite.

Yes! I know it. And I have thinking on this. My conclusion is:

• When one command "Change Frequency" is executed, then the diverHandler is stopped and incoming buffer is flushed. Until new data arrives again, there will be no new data out. This will be detected by the DAB player as a simple "bitstream interruption". But this isn't a problem because it needs to "restart" to the new frequency when new data starts to come.

Therefore, no problems in common environments. Only when a SYNC output will be required the problem needs to be targeted. And for this special case (a total different issue, commented in #26) I have one idea to target it... (I write in the other there as here has no sense).

Regards.

[JvanKatwijk]

Lars18th: making any progress?

[lars18th]

Lars18th: making any progress?

I'm very busy. However, with a lot of ideas. I'll prepare some implementations soon. Keep on hold!

[andimik]

What does "soon" mean here? It was 5 months ago...

[JvanKatwijk]

closing this